LosTechies Master Site Feed Comments

Backbone vs Knockout (17)

kizi friv — Fri, 17 May 2013 03:30:00 +0000

Very good informative post that you have shared and thankful your work for sharing the information. Got some entertaining information and would like to give it a try. Appreciate your work and keep sharing your information

Eventual consistency in REST APIs (4)

AquaBirdConsult — Fri, 17 May 2013 01:06:00 +0000

I’m a long time RavenDB user, and with the latest versions (2.0) of RavenDB the indexing is so fast I doubt you would be able to query fast enough to hit a stale index (although it is possible). It is even harder to hit a stale index if you are doing basic map indexes. Map/Reduce indexes is where you might hit stale results. Another approach to keep your data from getting stale is to leverage RavenDB’s Ids heavily, since loading a document using its Id is not bound to indexing.

User’s don’t realize wether you are serving them stale data or not, so I would probably ignore it in the case of Octopus deploy. I wonder what version he is using?

My choices would be Option 1 or Option 5. But I really do love RavenDB.

Entity Validation Ideation (7)

Mario T. Lanza — Thu, 16 May 2013 18:55:00 +0000

There are different flavors of validations. We have garbage validations (don’t allow bad data into a field) and relational validations (ensuring a proper multi-model construct where things are properly related in a graph) and business rule validations (particular to what makes sense in our domain’s workflow). Consider during a user session a user will have this interim state where he’s building up the transaction data. During the entire interaction as he moves from start to finish, we are at many times in a broken state violating rules on these three levels.

Over what construct are you proposing your proactive validations be run? Are they being run over the controls or over some data model that is built up behind the controls?

In a CRM, we have customer records, contact records (emails, phone numbers), address records, and purchase order records which themselves have line item records. Our business rules state: we never create a customer record until we have their first order and a customer must have at least one point of contact and one address. For a customer service rep to take a sales call, he has to build up that first transaction. From a human standpoint there is no way he can enter all these parts simultaneously, so he has to build up that transaction into an acceptable state. That build up must occur somewhere. Where? I’m assuming a data model. I’m assuming we run our validations over that “working” data model before we persist it.

However, remember that during the build up of the transaction we have partial data that is not ready for a commit. In my mind that working data model is the source from which we persist. Are you recommending that we have a clean model that is never in an interim, broken state and a separate working model that may be? And if so, won’t reconciling those two representations pose a huge synchronization mess? I need a little help in realizing the semantics of how one might implement proactive validations. I have always allowed the working model (the one being built up in the session) to exist in a broken state. I just required that the state be fixed before a commit.

Building forms for deep View Model graphs in ASP.NET MVC (22)

Jalpesh Vadgama — Thu, 16 May 2013 13:19:00 +0000

good work!! I found what I was searching for.. Thanks for sharing!!

Tip to become a successful software engineer. (24)

EdwardHaley — Thu, 16 May 2013 09:01:00 +0000

Being skilled about the several sorts of development tools has aided me do well as a software developer. and this is because of my interest towards software development as it is a wonderful business venture currently

Eventual consistency in REST APIs (4)

Jonathan Oliver — Thu, 16 May 2013 03:43:00 +0000

I like option 2+3 the most: 202 on writes and “last modified” on reads. The last-modified information could even be returned as a response header (please use ISO 8601 for dates) rather than cluttering up the response body.

RabbitMQ for Windows: Fanout Exchanges (3)

derekgreer — Tue, 14 May 2013 13:08:00 +0000

Thanks, Patty. This has been updated.

RabbitMQ for Windows: Fanout Exchanges (3)

Patty — Tue, 14 May 2013 04:54:00 +0000

This is really helpful! You do have one typo above that you might want to correct:

ExchangeDeclare(“direct-exchange-example”, ExchangeType.Fanout,…

should be:

ExchangeDeclare(“fanout-exchange-example”, ExchangeType.Fanout,

EmberJS: Initial Impressions (Compared To Backbone) (27)

slowhands — Mon, 13 May 2013 02:41:00 +0000

I agree with this post 100%. The takeaway for me is that EmberJS gives us lots of help keeping things together, sort of like a puzzle that pieces itself together. The conventions are nice and all, but there’s a rebel inside of me. Even though the instructions in the box are for building a car, I’m building a space ship.

Zombies! RUN! (Managing Page Transitions In Backbone Apps) (75)

Vikram Pawar — Sun, 12 May 2013 18:12:00 +0000

Thanks dude. You’re a life saver!

Thanks ADNUG attendees! Slides and code available. (4)

MichaelFreidgeim — Sat, 11 May 2013 23:42:00 +0000

Link to your slides is broken.

Ditching two-phased commits (11)

yepi6 — Sat, 11 May 2013 07:35:00 +0000

Thanks, the article gave me much more useful information.

Messages, data and types (6)

kizi2 — Sat, 11 May 2013 07:31:00 +0000

very good article, the message is personal matter and I want them to be safe.

There can be only One RoleEntryPoint (11)

yepi6 — Sat, 11 May 2013 05:23:00 +0000

wish you would handle the problem quickly.

Portable Areas three years later – Part 5 (12)

erichexter — Fri, 10 May 2013 18:34:00 +0000

You could use the common service locator

Portable Areas three years later – Part 5 (12)

Nobody Real — Fri, 10 May 2013 17:54:00 +0000

I don’t think Shortbus is a proper solution, as it depends on StructureMap. If you choose to use Ninject or Windsor, there should be no reason to be required to use SM.

Simple Async HTTP Module for Appcelerator (5)

Michael Stelly — Fri, 10 May 2013 17:33:00 +0000

perfect! i was able to create an http module for my Alloy project. thx.

Ditching two-phased commits (11)

jbogard — Fri, 10 May 2013 13:30:00 +0000

Most queueing technologies provide acknowledgements that a message has been accepted (handling is a separate deal). That’s why you have “at least once” supported by just about everyone.

Ditching two-phased commits (11)

Mark Allen — Fri, 10 May 2013 11:53:00 +0000

Ultimately, the question I’m trying to answer is without DTC, how are you assured that you are not losing messages, hence having to deal with none-or-at-least-once messaging rather than at-least-once messaging?

Ditching two-phased commits (11)

Mark Allen — Fri, 10 May 2013 11:13:00 +0000

Great post. We leverage NServiceBus quite heavily, and while we bask in the convenience of 2PC exactly-once messaging, we anticipate that as we scale this is going to break down due to performance issues.

So without DTC, how do you ensure that a message sent to a queue actually makes it? Is the Bus.Send basically an atomic operation, whereby if it succeeds then you are assured it has made it to the destination queue? I understand the notion of at-least-once messaging, but am nervous about the scenario where the sender thinks the message is delivered, but it actually never makes it to the intended target queue.