Obviously anyone who uses MSDN online knows it been updated and now looks like a really poor MySpace page!
But I did find one feature I really like today - 'ScriptFree' mode, this is a god send in a company environment pages now load in near light-speed, check out the 'Switch View' options on the righthand side of this page.
Hopefully they'll bring out a '1992 Times New Roman' version soon ;)
Awkward Coder
Monday, 14 December 2009
Thursday, 3 December 2009
Schrödinger's Service
Where I currently work the team has a set of SOA services that are used by alot of different app teams in the bank. In the UAT environment we occasionally get support issues where people can't access the services - they're receiving 404 errors!
When ever we check the services locally or remotely they're working fine and have been all the time - it appears the problem is in the infrastructure between the app team and the service endpoints. This doesn't really help our perception to rest of the bank and it's a bitch to resolve!
So we've come up with a name for the services 'Schrödinger's Services' - by the act of observing the services we've confirmed they're operating correctly and they then work for the app team as well. This happens every time we get this support query.
Check out wiki for the origin of the name.
Awkward Coder
When ever we check the services locally or remotely they're working fine and have been all the time - it appears the problem is in the infrastructure between the app team and the service endpoints. This doesn't really help our perception to rest of the bank and it's a bitch to resolve!
So we've come up with a name for the services 'Schrödinger's Services' - by the act of observing the services we've confirmed they're operating correctly and they then work for the app team as well. This happens every time we get this support query.
Check out wiki for the origin of the name.
Awkward Coder
Wednesday, 2 December 2009
Can I make a value object from an entity?
I've built a rich domain model for a private app I'm working on, it feels right, it got the correct mix of business functionality and models the domain problem very well, it even has flexibility for the future. I consciously had to keep focusing the domain expert and myself on the current iteration and not the future!
So I reached a point where I want to expose a 'view' depending on the 'context' of usage.
Simply put I want to expose data from some of the entitles as a 'catalog'. This catalog is immutable - the users of the catalog can't change or modify the contents they can only 'view' what is available. Items in the catalog don't contain an entity identifier and they only contain a subset of an entities data. This catalog item is starting to sound like a value object to me...
So the question is; Can I create a value object from an entity?
I think it's perfectly acceptable to do this - remember a value object should be immutable, the sub-text of the question for me is; is it acceptable to expose value objects via a service? I want a service that allows searching & returning of catalog items (with pagination etc). I also think this perfectly acceptable approach.
I suppose what I've defined here is a 'context' boundary for the core domain model - 'bounded context'.
Awkward Coder
So I reached a point where I want to expose a 'view' depending on the 'context' of usage.
Simply put I want to expose data from some of the entitles as a 'catalog'. This catalog is immutable - the users of the catalog can't change or modify the contents they can only 'view' what is available. Items in the catalog don't contain an entity identifier and they only contain a subset of an entities data. This catalog item is starting to sound like a value object to me...
So the question is; Can I create a value object from an entity?
I think it's perfectly acceptable to do this - remember a value object should be immutable, the sub-text of the question for me is; is it acceptable to expose value objects via a service? I want a service that allows searching & returning of catalog items (with pagination etc). I also think this perfectly acceptable approach.
I suppose what I've defined here is a 'context' boundary for the core domain model - 'bounded context'.
Awkward Coder
Wednesday, 18 November 2009
Continents move faster than the software industry!
Read this last week and it shows how dynamic and fast moving the software industry really is!
Awkward Coder
Awkward Coder
Removing friction from the process
Wednesday, 11 November 2009
build for test != build for release
This might seem obvious to a lot of people - the people who actually do testing, but to everyone who doesn't or just waves a derogatory hand in the general direction it isn't...
The differences manifests it's self in how the codebase is structured in your source control system. A codebase setup for test will have all the dependencies in the correct structure so when you pull the codebase, build the code and execute the tests you don't have to know what or how it's installed when the application is released - seems obvious right!
I've just attempted to do this and low and behold a missing dependency, I don't know the application and I don't particularly want to right now but I'm going to have to spend sometime just to get the code to build - I suspect I need to install some application on the system before I can build let alone test - WRONG, WRONG, WRONG!
Shite developers and there are a few, seem to think this job is about friction - friction pulling the code, friction building the code, no testing and friction deploying the code. These are the default parts of the job - we all have to do this so it should be automated and frictionless.
The differences manifests it's self in how the codebase is structured in your source control system. A codebase setup for test will have all the dependencies in the correct structure so when you pull the codebase, build the code and execute the tests you don't have to know what or how it's installed when the application is released - seems obvious right!
I've just attempted to do this and low and behold a missing dependency, I don't know the application and I don't particularly want to right now but I'm going to have to spend sometime just to get the code to build - I suspect I need to install some application on the system before I can build let alone test - WRONG, WRONG, WRONG!
Shite developers and there are a few, seem to think this job is about friction - friction pulling the code, friction building the code, no testing and friction deploying the code. These are the default parts of the job - we all have to do this so it should be automated and frictionless.
Friday, 6 November 2009
When I'm a new team member
Jsut had a meeting about how to improve the build process for the team - the current structure of the code in the source control system means I can't just get the code out and build it - this to me is the sign of a failing project\team!
I believe every project should be structured so that the following use cases are valid for any new developers coming onto a team, there's nothing more demoralising to new team members when you have to some kinda of voodoo to get a project to build;
As a developer I want to install the IDE So that I can compile source code.
As a developer I want to install the source control client So that I can extract code for compiling.
As a developer I want to compile the code So that I can verify the code compiles sucessfully.
As a developer I want to install a unit test framework So that I can execute unit tests for the code.
As a developer I want to execute the unit tests for the code So that I can verify the tests execute successfully.
Now this is not about being able to the run the application in a local debug build this about being able to confirm I'm standing on firm ground and I'm ready to start making changes to code base with confidence. (because the unit tests are all successful). For me one of the reasons for unit testing is to give team members & new starters the confidence to change code I've written without requiring my hand-holding.
There's nothing worse than being a new team member and not being productive ASAP.
Awkward Coder
I believe every project should be structured so that the following use cases are valid for any new developers coming onto a team, there's nothing more demoralising to new team members when you have to some kinda of voodoo to get a project to build;
As a developer I want to install the IDE So that I can compile source code.
As a developer I want to install the source control client So that I can extract code for compiling.
As a developer I want to compile the code So that I can verify the code compiles sucessfully.
As a developer I want to install a unit test framework So that I can execute unit tests for the code.
As a developer I want to execute the unit tests for the code So that I can verify the tests execute successfully.
Now this is not about being able to the run the application in a local debug build this about being able to confirm I'm standing on firm ground and I'm ready to start making changes to code base with confidence. (because the unit tests are all successful). For me one of the reasons for unit testing is to give team members & new starters the confidence to change code I've written without requiring my hand-holding.
There's nothing worse than being a new team member and not being productive ASAP.
Awkward Coder
Subscribe to:
Posts (Atom)
