LosTechies - Latest Comments

Re: How-To add a custom validation method to the jQuery validator plug-in

Wed, 22 May 2013 08:15:37 -0000

Nice

Re: Force .NET application to run in 32bit process on 64bit OS

elopezrios — Mon, 01 Apr 2013 20:12:43 -0000

Hi, when a Process is created from an 32bit image it's not possible to use 64bits assemblies. When a process is created from 64bits image, it can't load a 32bits DLL. It's a Windows restriction

Re: Migrating to Git

mck ☠ — Thu, 21 Mar 2013 04:18:29 -0000

Checkout FINN.no's story of migrating to Git http://tech.finn.no/given-the-...

A number of similarities, and in addition it covers GitHub Flow, maintaining externals forks, and Atlassian Stash.

Re: Dynamic reflection versus static reflection

Michael Freidgeim — Wed, 20 Feb 2013 07:04:38 -0000

According to http://stackoverflow.com/quest... static reflection is slower than classic one.

Re: Synchronizing calls to the UI in a multi-threaded application

Groverboy — Tue, 22 Jan 2013 19:33:40 -0000

Very nice generalised design, thanks for sharing this. I've been using SynchronizationContext for some time and definitely find it preferable to using Control.BeginInvoke.

A minor criticism: cancellation does not look thread-safe. The worker thread reads class field stopRequested (QuoteService.Run) and the consumer thread writes to the field (QuoteService.Stop), but there is no thread synchronisation to prevent a race condition. This means the consumer may call Stop and begin writing to stopRequested when the worker thread reads the field (stopRequested still equals false), resulting in an additional iteration beyond the consumer request to cancel.

Thread synchronisation can be implemented by using either a lock statement or qualifying stopRequested by 'volatile'.

So far as I know the race condition here has a minor consequence (potentially delayed cancel) unlike, for example, deposit to/withdrawal from a bank account. Can anyone think of a situation in which delayed cancel becomes a significant problem?

Re: Step-by-step Introduction to Delegates and Lambda Expressions

Rvsawant21 — Thu, 27 Dec 2012 05:39:18 -0000

simplest yet most effective article on lambda expression , expression tree... I have read so far. Thanks for a great post.

Re: NHibernate 3 Beginners Guide published

Vervidian — Thu, 22 Nov 2012 09:27:59 -0000

which i can buy this book , i need it , give me a path or websit address then i can pay for money. my email is vervidian@gmail.com. thx so much.

Re: NHibernate 3 Beginners Guide published

Vervidian — Thu, 22 Nov 2012 09:27:24 -0000

which i can buy this book , i need it , give me a path or websit address then i can pay for money. my email is vervidian@gmail.com. thx so much.

Re: Walking through the creation of a complex installer package

LittleFox — Thu, 22 Nov 2012 08:50:36 -0000

What can I do if I have to work with versions???
I mean, if I create a msi with version 1.0 and then I'd like to add some dlls to my existing website, can I just create a repair (1.1) and ask to someone run it for me?? I expected that this new version (1.1) will copy only the files that is new!

To do that the Guid's has to be the same every time, and only the new files added in the project has to be created with a new guid.

Is there a way to do that?
Thanks, this post is perfect and i really appreciate this... seriously.

Re: The open closed principle

Per Mikkelsen — Fri, 26 Oct 2012 04:00:32 -0000

Thanks - Very nice article.

Re: Synchronizing calls to the UI in a multi-threaded application

Mike — Mon, 24 Sep 2012 15:40:51 -0000

Million-dollar article! Thanks a million! ;)

Re: Synchronizing calls to the UI in a multi-threaded application

Freon — Sat, 22 Sep 2012 22:19:24 -0000

Fantastic little mechanism that solves the (thread)=>GUI problem nicely. Is scaleable and simple. WIN!

Re: The Dependency Inversion Principle

Keshav Baweja — Thu, 16 Aug 2012 00:47:38 -0000

Hi, the blog is easy to read but is a copy of Robert Martin's post on Object Mentor.

Re: How we got rid of the database–part 6

Bono — Thu, 09 Aug 2012 19:58:47 -0000

Did I miss the follow up post?

Re: How we got rid of the database–part 6

C Granwehr — Thu, 09 Aug 2012 04:23:08 -0000

Hello Gabriel, thanks for the so far great introduction into CQRS an ES. After a summerday outside in the garden, watching Greg Young's long video, your posts were very refreshing. I mostly appreciated the sample code you provided. Debugging working code helps a dummy like me a lot to understand what your're talking about. Please also integrate this and further posts into your solution (and don't forget to spend your free time without a computer)

Liebi Grües us de Schwyz von mir und dä Alex.

Re: How we got rid of the database–part 6

gabrielschenker — Sat, 21 Jul 2012 06:40:44 -0000

Sorry for the delay, but I was just too busy lately. But the next post is nearly ready to be posted. Thus stay tuned :)

Re: How we got rid of the database–part 6

Jiggaboo — Sat, 21 Jul 2012 05:06:35 -0000

Aaaaa. I 've read all 6 posts in 30 minutes and there is no next post and I have to wait (don't know how long) for post no 7. That's why I prefer books.

Re: How we got rid of the database–part 6

Dominic Delmolino — Thu, 05 Jul 2012 13:47:57 -0000

Looking forward to that post -- so far nothing I've read in this series explains why you needed to get rid of the database. You still have a database, you just call it a file store. Sounds like you *HAVE* gotten rid of the need for the application to be bound to a data model ala an ORM, which does sound good.

Re: How we got rid of the database–part 5

Thomas — Thu, 05 Jul 2012 08:51:28 -0000

Gabriel,

Where does the command dispatcher lives in the layered applications ? I guess it's an application layer and all other components in the domain.
How do you implement it ? I can't find it in the source code.

Re: How we got rid of the database–part 6

Rinat Abdullin — Wed, 04 Jul 2012 22:17:51 -0000

@Etienne Tremblay having run ES-based for years in various environments (e.g. mixture of local servers and cloud deployments), I must admit that file-level problems are extremely rare. Mostly it is caused by the fact that we store SHA1 with each record, while verifying it on each operation.
Second, it is extremely easy to set up continuous and immediate replication to multiple secondary locations off-site, to reduce disk corruption risks.

Re: How we got rid of the database–part 6

Rinat Abdullin — Wed, 04 Jul 2012 22:14:54 -0000

@Etienne Tremblay , in the case of thorough event sourcing, the simplest approach to versioning is to simply create a new event (_v2) with additional field. More complex scenarios involve, for example, use of Protocol Buffers (with their native ability to handle changes in serialization contracts) and use of in-memory upgraders to make sure that such events apply to the entire event history.
Fortunately, when your aggregates are designed using DDD approach, events do not change that often.

Re: How we got rid of the database–part 2

Rinat Abdullin — Wed, 04 Jul 2012 22:04:11 -0000

@nyxiscoo1 , failure detection is handled at slightly higher level in this approach. In essence, if server blows up, while we are in the middle of message processing (either command message or event message), then this will mean that message itself was not handled (and hence not removed from the queue).
This will mean that next time server starts up - it will automatically try to process the message again, hitting the failed event store and throwing up a real exception.

BTW, I'm currently testing alpha version of the next version of file event store, which should be able to provide better performance and better handling of random server fails. Latest version is currently available in lokad-iddd-sample at github.

Re: How we got rid of the database–part 6

gabrielschenker — Wed, 04 Jul 2012 14:42:45 -0000

I see, I have to write another blog post about why we do not use a database. A lot of readers do not seem to completely understand our motivations...
Just as a short note: we do not trade in "the devil with the belzebub".

Re: How we got rid of the database–part 2

gabrielschenker — Wed, 04 Jul 2012 14:37:57 -0000

Since I did not yet have any time to verify your findings I forwarded your concern to the author of the Lokad.CQRS "framework" Rinat Abdullin. I will also have another look myself.

Re: How we got rid of the database–part 2

nyxiscoo1 — Wed, 04 Jul 2012 14:04:52 -0000

Hi Gabriel,
I've looked at FileTapeStream and other implementation of storages at Lokad.CQRS, and it turned out thet they are absolutely not fail safe.

For example: if unexpected system reboot occured at the time of writing event, and last record was just partially written, FileTapeStream will throw exception on attempt to load such file. And as a result of using one file per aggreagation root you'll receive this error only next time this root will be addressed.

Have you any mechanism to prevent this?

Sorry for my english)