Like this:

Thanks for everyone who’ve attended my CodeCamp presentation. Thanks for organizers for making it happen.

I’ve had a chance to build the realistic distributed application live-coding from scratch. The application consisted from 2 roles – web role and a worker role. During the demo I’ve used the Amazon AWS cloud, but the similar technique can be applied to Azure deployments.

The audience was great and engaging even though we didn’t have enough and I was flying through the code.

The code I’m publishing (Amazon AWS demo) is a beautified version of the one we’ve created during the Code Camp.

Stay tuned for the mirrored Azure demo code…

NOTE: This is a simplified version and should not be treated as a real-life application.

Like this:

We’ve had a lot of fun with a small party talking about RavenDB, it’s functionality and quirks. We’ve wondered of track into more advanced topics of Replication, Sharding and Security so I totally forgot to talk about the transactional support for RavenDB (including DTC). Now I know for sure that 2 hours discussion about RavenDB is not enough. It looks like I’ll need to split the presentation into the “intro” and “advanced” parts.

Like this:

Here is the other part of our presentation for the NEVB user group – Overview of RavenDB. Due to some technical problems was no able to show much of the code and really feel bad about that. Hope to get another chance to talk more about RavenDB.

Like this:

Recently Phil Young and I gave presentation about NoSql, RavenDB and Hadoop to NEVB User Group. This was our first presentation of this kind and format and we’ve had a couple of snags running it, but, I promise, we’re getting much better at that.

I’ve just published the first portion of the slides about the NoSql introduction. Feedback is always welcome.

Recently we’ve delivered a presentation to the Boston Azure User Group on how perfectly the cloud technologies are aligned for development for the Mobile Apps and clients. My coworkers from Blue Metal Architects delivered great content about integrating iOS (featured iPhone and iPad) and Windows Phone with the cloud. I’ve covered the use of the AppFabric Service Bus Queues and Topics – these technologies are perfect for communications for partially connected clients (like mobile ones).

It’s designed to improve performance. “The essence of deliberate practice is continually stretching an individual just beyond his or her current abilities. That may sound obvious, but most of us don’t do it in the activities we think of as practice.”

It’s repeated a lot. “High repetition is the most important difference between deliberate practice of a task and performing the task for real, when it counts.”

Feedback on results is continuously available. “You may think that your rehearsal of a job interview was flawless, but your opinion isn’t what counts.”

It’s highly demanding mentally. “Deliberate practice is above all an effort of focus and concentration. That is what makes it ‘deliberate,’ as distinct from the mindless playing of scales or hitting of tennis balls that most people engage in.”

It’s hard. “Doing things we know how to do well is enjoyable, and that’s exactly the opposite of what deliberate practice demands.”

It requires (good) goals. “The best performers set goals that are not about the outcome but rather about the process of reaching the outcome.”

Hard work is deliberate practice. It’s not fun while you’re doing it, but you don’t have to do too much of it in any one day (the elite players spent, on average, 3.5 hours per day engaged in deliberate practice, broken into two sessions). It also provides you measurable progress in a skill, which generates a strong sense of contentment and motivation. Therefore, although hard work is hard, it’s not draining and it can fit nicely into a relaxed and enjoyable day.

Hard to do work, by contrast, is draining. It has you running around all day in a state of false busyness that leaves you, like the average players from the Berlin study, feeling tired and stressed. It also, as we just learned, has very little to do with real accomplishment.

The solution is as simple as it is startling: Do less. But do what you do with complete and hard focus. Then when you’re done be done, and go enjoy the rest of the day.

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.