Написал там, напишу и здесь. Azure Functions — это "serverless" скрипты, которые могут быть написаны на C#, F#, JS, PHP, Python и пр, поставлены на таймер (через cron expression), или на триггер (по http запросу, на событие в шине, на сообщение в очереди, на новые данные в сторадже и т.д.) и выполняющие какие-то действия.
Они интегрированы со всеми Azure технологиями, пайплайнами, бигдата хранилищами, api и пр.
Оплата за кол-во использований и за время работы, т.е. виртуалку можно не держать 24/7, а платить только за скорость кода :)
Очень хочу поддержку этой технологии в Rider, потому что Rider — хорош, но работать с enterprise технологиями пока не получается.
Честно скажу, писать реквест на Azure Functions не буду, т.к. понимаю что это очень нишевая технология, которую даже VS плоховато поддерживает. А у Rider ещё много других проблем. Даже реквест, который Вы линканули, касающийся общей интеграции с Azure, как я понимаю, ещё не выполнен.
Для начала стоит вести версионирование api.
А деплой подобных компонентов может происходит так:
1) новая версия деплоится на резервную машину и запускается
2) балансировщик переключается на резервную машину (все запросы теперь шлются туда)
3) деплоится новая версия на основную машину
4) основная становится резервной (опционально)
Да, мы тоже используем на уровне поддержки. Новые сервисы пишутся как webapi. Для велосипедов сложнее используется akka.net и rabbitmq. Плюсы? Это ещё бОльший конструктор, нет завязки на msmq, можно присоединять другие экосистемы через тот же rabbit.
У меня вопрос был не к технологии, а к статье, которая по сути хеллоуворлд, да ещё и в 2015 студии. Разницы в коде конечно не будет, но человек явно забыл обновить тулы.
Прозрачное описание персистентности в Akka лежит в понимании EventSourcing.
Нужно сделать актора, который реагирует на команды. Изменение состояния происходит через генерацию и сохранении событий в хранилище. При восстановлении состояния читается поток событий и проигрывается заново реакция на них.
Персистентность руками делать не надо, просто подключаем плагин из готовых и работаем.
Если надо по-быстрому, то есть плагин для embedded SqLite.
Это не Lync!
Написал там, напишу и здесь.
Azure Functions — это "serverless" скрипты, которые могут быть написаны на C#, F#, JS, PHP, Python и пр, поставлены на таймер (через cron expression), или на триггер (по http запросу, на событие в шине, на сообщение в очереди, на новые данные в сторадже и т.д.) и выполняющие какие-то действия.
Они интегрированы со всеми Azure технологиями, пайплайнами, бигдата хранилищами, api и пр.
Оплата за кол-во использований и за время работы, т.е. виртуалку можно не держать 24/7, а платить только за скорость кода :)
Очень хочу поддержку этой технологии в Rider, потому что Rider — хорош, но работать с enterprise технологиями пока не получается.
В начале это связано с этим — https://youtrack.jetbrains.com/issue/RIDER-8429 (обещали сделать), т.к. без fsx вообще ничего не заработает.
Честно скажу, писать реквест на Azure Functions не буду, т.к. понимаю что это очень нишевая технология, которую даже VS плоховато поддерживает. А у Rider ещё много других проблем. Даже реквест, который Вы линканули, касающийся общей интеграции с Azure, как я понимаю, ещё не выполнен.
Поддержу реквест. RIder вообще не понимает *.fsx сейчас.
Azure Functions — это сейчас моя основная деятельность, пришлось перейти обратно на VS.
Поддержу вопрос и напомню, что термин актор (ударение на первый слог) существует в математической и компьютерной теории с 1973 года.
Для начала стоит вести версионирование api.
А деплой подобных компонентов может происходит так:
1) новая версия деплоится на резервную машину и запускается
2) балансировщик переключается на резервную машину (все запросы теперь шлются туда)
3) деплоится новая версия на основную машину
4) основная становится резервной (опционально)
Работаем.
Да, мы тоже используем на уровне поддержки. Новые сервисы пишутся как webapi. Для велосипедов сложнее используется akka.net и rabbitmq. Плюсы? Это ещё бОльший конструктор, нет завязки на msmq, можно присоединять другие экосистемы через тот же rabbit.
У меня вопрос был не к технологии, а к статье, которая по сути хеллоуворлд, да ещё и в 2015 студии. Разницы в коде конечно не будет, но человек явно забыл обновить тулы.
Никакого развития. Поддержки в netcore не предвидится.
На дворе 2017ый, а на хабре статьи про WCF (технология без будущего), написанный на VS2015...
Ожидал увидеть — "Как на netcore-2.0-preview запустить WCF через RabbitMQ"
Нет, не ломает. Желательно скриншот и объяснение.
Допустим TimeSpan.FromSeconds(1)
Если что код я выложил: https://pastebin.com/fZ7EBGe3
В CanExecute() происходит атомарный декремент числа (никаких походов в heap, всё на стеке). Если число меньше 0, то атомарно инкрементим обратно.
По таймеру происходит обратное. Инкрементим, и если токенов стало очень много — декрементим.
Переменную можно сделать volatile чтобы она случайно незакешировалась в проце.
Тогда спешу сообщить, что на моей машине вызов CanExecute() из моего решения с атомарными операциями занимает 12нс, а из вашего — 42нс.
Измерял BenchmarkDotNet.
Тогда могу сказать что в Вашей задаче не хватает требований, которые Вы придумываете на лету, и которые никто кроме Вас не знает.
Способов реализации того, что описано в начале статьи (2 пункта) — масса. В том числе с помощью стандартных инструментов, с которыми Вы незнакомы.
Что в данном случае понимается под скоростью — остаётся загадкой.
Проигрывает по скорости чего? Скорость выполнения CanExecute()?
Нужен критерий перформанса.
Через коллекцию токенов можно посмотреть как в Akka.Net реализован Throttle.
А через атомарные операции и таймер:
https://pastebin.com/fZ7EBGe3
Вызов таймера выполняется через ThreadPool
Вам бы книжку какую почитать, а то получается что Вы не в курсе, а виноват почему-то C#
BlockingCollection Overview
Interlocked Operations
Вагиф на прошлом Московском DotNext рассказывал о своём проекте:
https://www.youtube.com/watch?v=wRxO5ky7S8g
Всё ещё можно. Просто пропишите файл как content и он nuget pack'ом будет доставляться при установке.
Нужно сделать актора, который реагирует на команды. Изменение состояния происходит через генерацию и сохранении событий в хранилище. При восстановлении состояния читается поток событий и проигрывается заново реакция на них.
Персистентность руками делать не надо, просто подключаем плагин из готовых и работаем.
Если надо по-быстрому, то есть плагин для embedded SqLite.
Немного привыкнув к Scala код можно передирать почти 1:1, т.к. фреймворк полностью портирован.