Wednesday, September 26, 2012

RavenDB Expiration Bundle

In RavenDB there is an expiration bundle.  This is great, think of it as a document retention policy.  Delete me in 90 days from now.  There is an issue in build 960 when you have both replication and expiration bundles installed.  Save ten documents test/1, test/2, and so on.  Set the expiration for 1 minute from now.

In Silverlight you will see the documents, but in 60 seconds you won’t.  The collection will still show a count of 10 documents.  Not the end of the world, the app still works, and no one can READ the documents that have expired.  But they still exist, they will be delete later.

Suppose you want to see the expired documents using the Expired Docs index.  Can’t the Read task prevents this from happening.  They are there and indexed, but there is a trigger that is preventing reads from happening.

This issue is fixed in the next release, but if you have a bunch of deletes on a large data set… it will be interesting to see if the counts are still a bit off in the admin console, possibly even query counts for pagination, just until the index catches up.

Sunday, September 23, 2012

RavenDB Replication

Doing some pre release testing or RavenDB Replication in build 960.  Thought I’d log and share my results.


  • Create Two folders 8080 and 8081
  • unzip code base into each one
  • In server folder –> create plugins folder
  • from bundles folder –> copy the dlls for  –> replication, expiration
  • copy in my custom replication conflict resolution dll
  • edit server config -> change ‘get’ to ‘all’
    • change port setting from * to 8080 and 8081 depending on which folder I’m in.
  • Start Servers –> things look good.
  • Testing
    • Stop and start servers, look at logs.


I have a series of single task executable files I need to run.  Some set up our environment, others push data.

Testing Create Tenants exe
  1. Run exe against server:8080 then server:8081
  2. Check to see if databases are there –> they are all good.
Replication Configuration and Testing
  1. Create a document Test/101 on server:8080, using the Silverlight tool.
  2. Configure Replication and Server:8081 –> follow help docs on
  3. Wait a bit -> type reset in command line –> nothing happens –> 8081 is not reaching out to 8080 and pulling in the documents
  4. Configure replication on server 8080 to reach out to 8081
  5. Still no replication happening
  6. Added document Test/102 to 8081
  7. Found the error, copy and paste problem
  8. Checking logs after fixed typo
  9. Documents are still not replicating – Adding document test/105 to 8080
  10. Replication was working, but was replication from server:8080/databases/ClientA to server:8081 /databases/default
  11. Changed the Raven/Replication/Destinations documents on both servers to
    {"Url": “http://dfrfrm025080:8080/databases/ClientA/”}
  12. Success, Replication is working.  Going to delete replicated records out of default database to prevent future confusion.
Replication Conflict Resolution Testing
  1. Turn off server:8081 –> using q command in console so I don’t get a bunch of index errors when I start again
  2. server:8080 edit Test/105 –> Change Name from “Jane” to “Tarzan” and Save
  3. Turn off server:8080
  4. start server:8081
  5. Make sure in ClientA database (database and tenant are about the same thing)
  6. Edit Test/105 –> change Name from “Jane” to “Superman” save
  7. Start Server:8080 and wait a bit for things to mesh
  8. Both documents say superman
  9. Now going to do the same thing but in reverse order, since the conflict resolution dll’s are installed on both servers.
  10. server:8081  test/105 – name “IronMan”
  11. server:8080  test/105 – name “Batman”
  12. Restarted both servers to speed things up
  13. Looks good now both say “Batman”
  14. Since I issued a restart, the test is not entirely valid, I’ll monitor this later when I start pushing large amounts of data.

Thursday, August 23, 2012

Zend Server

I'm in a demo of the next version of Zend Server.  The UI is nice.  Permission are a welcome feature.

Tuesday, August 21, 2012

Jimmy’s bad experience with TDD. Was it really TDD?

Jimmy is introduced to test driven development. He has all these shiny tools that have unlimited power. Naturally, he only substitutes his current style (code-> run->point click test) with an automated test test runner. After a few days learning curve Jimmy is happy, he is cranking away on his current project and getting more done than he ever imagined. He has confidence in what he is writing because everything is green. Life is good.

Then all the sudden,some of his tests are not green but red. He reverts his code to a previous version, still red. He reboots his computer, still red. Starts debugging, only to find the data changed. The DBA’s cleaned out all the test data. Jimmy has an idea, he will use his new shiny tools to create scripts to check if the data is in the database, if not, it will populate. He spends a few days getting it just right and working with his unit test. Everything is green again, life is good. He starts coding again. Then his data population scripts start acting funny. The DBA’s changed the structure. Jimmy, while frustrated makes changes.

Then the stakeholder asks Jimmy to make some changes to the site, the changes are not small, but not too big either. But Jimmy finds that to make the changes requires more work than he is used to because he has to refactor his code, then make changes to the test, right in the middle of this process, more database changes come in. Jimmy is getting nervous because he is running out of time. Faced with the reality that is project may be late, he essentially abandons his tests, makes the changes to his code to make the stakeholder happy. He has every intention of coming back to ‘fix his tests’. He never does.

Jimmy is not the biggest fan of unit testing. He avoids it for the next few projects.

Then one day, Jimmy is assigned to a management console project. This project is painful because every little change is a pain to test. He has to run the app, log in, click through 5 different menus, fill out a form with a bunch of required fields and then submit. Development is slow and not very much fun. Jimmy know he can get around some of these problems by shifting his coding style a bit, then he can use his unit testing tools, mainly the test runner, to save some time. But when that project is over, so is the testing. He would like to do more, but bad experiences have soured his enthusiasm for what he thought was TDD. In reality Jimmy never really did TDD.
This story was written for an intro to a presentation on TDD.

Friday, August 17, 2012

Fail Safe Test Driven Development



Dependencies – Anything outside of your code.  Database, files, web services,

Dependency Injection framework – framework to help you manage which concrete dependency to use based on a given context.  Example, use mock of ISqlRepo when testing but use real Sql2008Repo when not testing.

Testing Framework – usually has a test runner to run the tests and display the results of each test.  Usually has code framework to create assertions.  eg. Assert.IsTrue( 4 = 2 + 2);

Inversion of control – where you allow the calling method to have a say in how something is done.  saveUser(user, dao)    vs.  saveUser(user)

Mocking – Since you cannot new up an interface, a mocking framework will allow you to create a concrete object from an interface, or override existing functionality in a concrete class.  There are many fun things you can do with mocks like make them observable.  Then you can assert that a certain method is only called a certain number of times.  This can be surprisingly helpful.

Composability – think buffet, you can pick and choose.  Developer has a high degree of control.  vs. happy meal.

Test Friction – how hard is it for you to test your app

Repository Pattern – in short – new up an data model object for you with data.  If your data models are POCO objects, your repo get data from database or other and returns them to the app.

POCO/POPO – Plain Old C Object, Plain old PHP object – object with fields or properties no methods, save maybe getters and setters.

Smurf Naming Convention – When all the classes start with the same thing but add the action eg, CustomerOrderService, CustomerOrderRepo, ICustomerOrder, CustomerOrderDataModel


  • Language that supports TDD
    • HTML and CSS are not programming languages – limited ability to test
    • SQL is not a programming language – not easily suitable for TDD
  • Testing Framework
  • Mocking Framework
  • Dependency Injection Framework
You do not need a database, file system, browser, web server, version control system.  You should have version control, but you do not need one that supports testing to do TDD.


  • Highly maintainable
  • Low test friction
  • Inversion of Control
  • Loose coupling (not independence) 
  • Composability
  • Helping yourself and others
  • TDD is NOT about customer satisfaction or satisfying product requirements
  • TDD is about embracing the power of the native programming language, not reducing it to one line of code or hiding it.
  • Protect your code from dependencies
  • Avoid the temptation for integration testing – you will fail
  • Be prepared to work around what you cannot test.


The layers in an app are highly dependent on the app and the goals of the app. You may need each layer to be portable for other projects. On they can just be folders in your existing project.

  • Data Models
  • Application Interface
  • Repo Interface
  • Business Logic – no dependencies 100% your language and under test
  • Application – this is where the layers come together in a loosely coupled fashion to create your app. Your app is just a composition of each of the layers.
  • Tests – not really a layer but should be part of your solution but not part of your application.


  • Static methods are bad
  • Private methods are bad
  • Starting with tests is important if you want the tests to drive the development 
  • Public methods are good
  • Interfaces are good – how you can control the supported footprint (vs. private methods)
  • Repository Pattern is your friend
  • In MVC skinny models and fat controllers
  • Use constructors to set your dependencies
  • Layers – this requires some practice and discipline
    • Tests should never reach into the application layers
    • Data Models have zero dependencies except the language (PHP, C#, Java)
    • Interfaces have one dependency: Data Models
    • Business Logic – one dependency:  data models (sometimes interfaces)
    • Repository – data models, and any database libraries, cannot reach into the application.
    • Application Logic – Data Models, Interfaces, Business Logic, Repository, Dependency Injection Framework, and many more.  This is where the composition happens.


  1. Create a sunny day interface test
  2. Create Data Models (POCO)
  3. Create Interface for repo or service – all depends on what you are building
  4. Use interface to create a mock object that you can test.

After you have a working test, start working backwards, start working on an implementation from the interface.  Create a new test, exactly as your mock but return your implementation not your interface.