#1 Option:
Add following tag into project file:
<Target Name="GatherAllFilesToPublish">
</Target>
But will output all of source files into web site.
#2 Option:
Replace
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="false"/>
To
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
Reference:
http://forums.asp.net/t/1838524.aspx?The+target+GatherAllFilesToPublish+does+not+exist
Friday, October 16, 2015
Wednesday, October 7, 2015
INTENTION REVEALING INTERFACES from DDD
Excerpt from DDD book:
"The beauty of objects is their ability to encapsulate all that so that client code is simple and can be interpreted in terms of higher-level concepts.
But if the interface doesn’t tell the client developer what he needs to know in order to use the object effectively, he will have to dig into the internals and understand the details. A reader of the client code will have to do that same. Then most of the value of the encapsulation is lost. We are always fighting cognitive overload. If the client developer’s mind is flooded with detail about how a component does its job, his mind isn’t clear to work out the intricacies of the client design. This is true even when the same person is playing both roles, developing and using his own code, because even if he doesn’t have to learn those details, there is a limit to how many factors he can consider at once."
It is so true if working on a larger dev team.
"The beauty of objects is their ability to encapsulate all that so that client code is simple and can be interpreted in terms of higher-level concepts.
But if the interface doesn’t tell the client developer what he needs to know in order to use the object effectively, he will have to dig into the internals and understand the details. A reader of the client code will have to do that same. Then most of the value of the encapsulation is lost. We are always fighting cognitive overload. If the client developer’s mind is flooded with detail about how a component does its job, his mind isn’t clear to work out the intricacies of the client design. This is true even when the same person is playing both roles, developing and using his own code, because even if he doesn’t have to learn those details, there is a limit to how many factors he can consider at once."
It is so true if working on a larger dev team.
Thursday, September 24, 2015
Another way to talk about CQRS/Event Sourcing
"A more promising model, used in some systems, is to think of a database as an always-growing collection of immutable facts. You can query it at some point in time — but that’s still old, imperative style thinking. A more fruitful approach is to take the streams of facts as they come in, and functionally process them in real-time."
Turning the database inside-out with Apache Samz
https://martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html
Turning the database inside-out with Apache Samz
https://martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html
Monday, September 21, 2015
Subscribe to:
Posts (Atom)