NoSQL Patterns

http://architects.dzone.com/articles/introduction-nosql-patterns

Worth reading.

Design Patterns in JavaScript

This is a nice compendium of patterns in JS. Quite easy and usefull when teaching that stuff with front end devs.
http://thoughtsonscripts.blogspot.com/2011/11/javascript-design-patterns.html

Great post on .NET performance

Good pointer, good actionnable pointers!, can be found here.The reference section is good too!

Google App Engine: cloud is not just hardware

More and more it becomes obvious that the cloud aspect of infrastructure will blur the distinction between what the application architecture has to take into account as a precondition and what it has to handle in its scope. This post from DZone is a great illustration on how taking the cloud into account is paramount to a successful project. You don't deal with it: you lose money; take it into account and you're as easily profitable.

The next-wave software architecture: DDD, DCI and Event Sourcing

http://jivejdon.blogspot.com/2011/09/ddd-dci-and-domain-events-example.html

As background reading:

• http://www.jdon.org/
• http://code.google.com/p/disruptor/
• http://martinfowler.com/articles/lmax.html

MMM: Modularity Maturity Model

This article: http://www.infoq.com/news/2011/09/mmm-osgi is a summary of a presentation. The article contains a pointer to the presentation.Although still a work in progress, it is already worth a look:

• Level 1:Ad Hoc. Nothing is modular. Everything is a bunch of JARs, or worse, a bunch of classes. Typically results in a monolithic application.
• Level 2:Modules. Modules have a formal versioned identity, and dependencies are done against the module identity rather than the units themselves. Maven, Ivy, RPM and OSGi fall into this category.
• Level 3:Modularity. Modules are declared via module contracts, not via explicit module identifier/versions. The requirements might be abstract (e.g. Declarative Services is available) or might be specific packages (e.g. org.osgi.framework).
• Level 4:Loose coupling. Implementations are not found via factories or constructors; instead, they are queried dynamically from a registry or injected on demand.
• Level 5:Devolution. Artefact ownerships are devolved to modularity-aware repositories. They may support collaboration or governance for accessing the assets by relation to the capabilities required.
• Level 6:Dynamism. Modules participate in a dynamic life cycle which includes the ability to add, update and remove modules at runtime, whilst preserving the state in the system.

Identity lifecycle

Event without considering the philosophical issues associated with this topic, Identity management is surprizingly complex!
Taken from http://www.digitalidnews.com/2011/09/27/id-lifecycle-101-credential-management

Issuing a credential is only the start of the identity lifecycle. As an individual moves around an organization, controlling and adjusting the systems he can and cannot access is equally important to the initial identity vetting. Throughout the ID lifecycle, this identity and credential management function is essential.

Silverlight vs Flex

I found a very well structured post on the comparison between Silverlight and Flex. It's almost a year old but remains relevant (to me at least): Find it here.

Wave security

ReadWriteWeb has a good post on Google's Wave security. What I take away from this article has less to do with Wave per se as with the fact that security was a concern addressed from the start. One would wish this would be the "obvious" approach not worth mentioning in an interview. Since it's not the case, kudos to Google for showing the way both with their products and with their methodology.

RESTful vs SOAP:a business case

Weird that CTO's still think of WS as needing to be SOAP. I though I was missing something, that there might be some virtue to SOAP I was unaware of. Seems I did not miss anything and that soap is not perceived as a waste only by me. You can read an articulated reflexion on this subject here.