Because of this feature in the library, I was able to deliver a full,
working copy of our project to our designers without having to install
any dependencies. That means no Azure SDK, no DBs, and most
importantly, no setup at all!
Using the following:
MemoryProcess
MemorySender
FileStreaming
FS implementation of Lokad.Cloud.Storage.ITableStorageProvider
SQLite
All it takes for our remote designers to run the app locally is a
publish of the web role, a git commit!
Thanks, man. I'm really glad things worked out that well for you!
In-memory stand-alone scenario was one of the primary drivers behind Lokad.CQRS v2. In my experience it massively reduced development friction and enabled a few more scenarios (in-memory unit testing, in-memory bus for desktop apps).
In the mid-term I'd love to add simple file implementation of the message queues, so that the stand-alone scenario would fit for the production scenarios as well. We have a few cases locally here for that (for servers outside of Azure), plus some people were showing interest in using Lokad.CQRS for non-Azure development as well.
We'll keep everybody updated.
All the best, Rinat
On Sat, Jun 18, 2011 at 7:12 AM, Chris Martin <chris.mar...@eventday.com>wrote:
> Because of this feature in the library, I was able to deliver a full, > working copy of our project to our designers without having to install > any dependencies. That means no Azure SDK, no DBs, and most > importantly, no setup at all!
> Using the following: > MemoryProcess > MemorySender > FileStreaming > FS implementation of Lokad.Cloud.Storage.ITableStorageProvider > SQLite
> All it takes for our remote designers to run the app locally is a > publish of the web role, a git commit!
> Thanks, man. I'm really glad things worked out that well for you!
> In-memory stand-alone scenario was one of the primary drivers behind > Lokad.CQRS v2. In my experience it massively reduced development friction > and enabled a few more scenarios (in-memory unit testing, in-memory bus for > desktop apps).
> In the mid-term I'd love to add simple file implementation of the message > queues, so that the stand-alone scenario would fit for the production > scenarios as well. We have a few cases locally here for that (for servers > outside of Azure), plus some people were showing interest in using > Lokad.CQRS for non-Azure development as well.
> We'll keep everybody updated.
> All the best, > Rinat
> On Sat, Jun 18, 2011 at 7:12 AM, Chris Martin <chris.mar...@eventday.com>wrote:
>> Are awesome!
>> Because of this feature in the library, I was able to deliver a full, >> working copy of our project to our designers without having to install >> any dependencies. That means no Azure SDK, no DBs, and most >> importantly, no setup at all!
>> Using the following: >> MemoryProcess >> MemorySender >> FileStreaming >> FS implementation of Lokad.Cloud.Storage.ITableStorageProvider >> SQLite
>> All it takes for our remote designers to run the app locally is a >> publish of the web role, a git commit!
Gotta make it quick. I just snuck in here to reply. The family is waiting. ;)
In VS, I have a configuration named "DebugInMemory". In that config, I build the the engine (with C# directives [1]) with only in memory, and FS stuff. It's in that config that I publish the web role (MVC3 app) and give it to the designers to work on CSS, JS, and Razor views.
It's not only for designers though, it makes for lightning fast development not having to wait for the emulator and such.
> Just a quick question. Could you, please, explain the process here? > I didn't quite understood what's happening here, but it sounds really > interesting.
> "All it takes for our remote designers to run the app locally is a publish > of the web role, a git commit!"
> Best regards, > Rinat
> On Sat, Jun 18, 2011 at 12:40 PM, Rinat Abdullin <rinat.abdul...@gmail.com > > wrote:
>> Thanks, man. I'm really glad things worked out that well for you!
>> In-memory stand-alone scenario was one of the primary drivers behind >> Lokad.CQRS v2. In my experience it massively reduced development friction >> and enabled a few more scenarios (in-memory unit testing, in-memory bus for >> desktop apps).
>> In the mid-term I'd love to add simple file implementation of the message >> queues, so that the stand-alone scenario would fit for the production >> scenarios as well. We have a few cases locally here for that (for servers >> outside of Azure), plus some people were showing interest in using >> Lokad.CQRS for non-Azure development as well.
>> We'll keep everybody updated.
>> All the best, >> Rinat
>> On Sat, Jun 18, 2011 at 7:12 AM, Chris Martin <chris.mar...@eventday.com>wrote:
>>> Are awesome!
>>> Because of this feature in the library, I was able to deliver a full, >>> working copy of our project to our designers without having to install >>> any dependencies. That means no Azure SDK, no DBs, and most >>> importantly, no setup at all!
>>> Using the following: >>> MemoryProcess >>> MemorySender >>> FileStreaming >>> FS implementation of Lokad.Cloud.Storage.ITableStorageProvider >>> SQLite
>>> All it takes for our remote designers to run the app locally is a >>> publish of the web role, a git commit!
Very interesting setup! My portability approach differs slightly.
Configuration bits are defined not by the pragma directives, but
rather by the configuration strings.
Also projects serve dual purpose. For example, given:
We can have F5 configured to run WebRole and WorkerRole locally
without Azure emulator fabric just because:
1. Web Role is a simple Web project by default. And it comes with
web.config with default settings. AzureSettingsContainer from
Lokad.CQRS happens to default to web.config/app.config, if there is no
Azure runtime around.
2. WorkerRole by default is a class project that is loaded by Azure.
However for the local scenario you can provide default app.config
along and compile it as console (Azure will not notice the
difference :)
Just for the record, here are a few missing bits from enabling the
proper local portability scenario:
1. Maintenance console (just to simplify debugging event streams,
looking at the views, rebuilding them etc)
2. File-based queues (just to be able to work in persisted mode
without Azure Storage)
3. Simple TCP/IP endpoint for the engine (to be able to push messages
directly to the engine-managed queues and query file-based views)
Just thinking, since there are a few people that are kindly offering
help with the project, I'll need to assemble a full blog post to cover
enabling features that are currently missing from the portability
core.
All the best,
Rinat
On Jun 18, 1:35 pm, Chris Martin <chris.mar...@eventday.com> wrote:
> Gotta make it quick. I just snuck in here to reply. The family is waiting.
> ;)
> In VS, I have a configuration named "DebugInMemory". In that config, I build
> the the engine (with C# directives [1]) with only in memory, and FS stuff.
> It's in that config that I publish the web role (MVC3 app) and give it to
> the designers to work on CSS, JS, and Razor views.
> It's not only for designers though, it makes for lightning fast development
> not having to wait for the emulator and such.
> On Fri, Jun 17, 2011 at 11:47 PM, Rinat Abdullin
> <rinat.abdul...@gmail.com>wrote:
> > Just a quick question. Could you, please, explain the process here?
> > I didn't quite understood what's happening here, but it sounds really
> > interesting.
> > "All it takes for our remote designers to run the app locally is a publish
> > of the web role, a git commit!"
> > Best regards,
> > Rinat
> > On Sat, Jun 18, 2011 at 12:40 PM, Rinat Abdullin <rinat.abdul...@gmail.com
> > > wrote:
> >> Thanks, man. I'm really glad things worked out that well for you!
> >> In-memory stand-alone scenario was one of the primary drivers behind
> >> Lokad.CQRS v2. In my experience it massively reduced development friction
> >> and enabled a few more scenarios (in-memory unit testing, in-memory bus for
> >> desktop apps).
> >> In the mid-term I'd love to add simple file implementation of the message
> >> queues, so that the stand-alone scenario would fit for the production
> >> scenarios as well. We have a few cases locally here for that (for servers
> >> outside of Azure), plus some people were showing interest in using
> >> Lokad.CQRS for non-Azure development as well.
> >> We'll keep everybody updated.
> >> All the best,
> >> Rinat
> >> On Sat, Jun 18, 2011 at 7:12 AM, Chris Martin <chris.mar...@eventday.com>wrote:
> >>> Are awesome!
> >>> Because of this feature in the library, I was able to deliver a full,
> >>> working copy of our project to our designers without having to install
> >>> any dependencies. That means no Azure SDK, no DBs, and most
> >>> importantly, no setup at all!
> >>> Using the following:
> >>> MemoryProcess
> >>> MemorySender
> >>> FileStreaming
> >>> FS implementation of Lokad.Cloud.Storage.ITableStorageProvider
> >>> SQLite
> >>> All it takes for our remote designers to run the app locally is a
> >>> publish of the web role, a git commit!
