I agree, Subversion is a terrible tool for deployment. So, don't use it for deployment. Try something like the pear installer.
One big problem that I've seen before is trying to put too much under SCC. For example, trying to manage all of your libraries and tool dependencies with SCC. Personally, I never use externals, nor do I check in code libraries that I haven't written. Been there, done that, bad news.
Well, that's exactly what I was doing. I was under the impression that Subversion would cope with that. I bought a copy of the PEAR Installer Manifesto but it told me nothing. I couldn't find any basic PEAR installer tutorials for deploying applications.
If you want to be productive, you should be acquiring most of this code from third parties.
Well that really depends on the quality of that third party code. Certainly when it comes to third party code in PHP 97% of the time I can do a better job myself. I'm referring specifically to the lack of TDD practise.
Architectural code is where the action is in PHP right now. This code is moderately reusable.
I've seen foundation libraries before they nearly always seem superfluous to me, especially considering PHP's existing function library. So naturally the community is interested in architectural code.
Robert martin has a lot of writing on the relationship between deployment, dependencies and reuse in his book "Agile Software Development."
Do you mean
this
The Release-Reuse Equivalency Principle - The granule of reuse is the granule of release
The Stable Dependencies Principle - Depend in the direction of stability
The Stable Abstractions Principle - A package should be as abstract as it is stable.
The Common Closure Principle - The classes in a package should be closed together against the same kinds of changes. A change that affects a closed package affects all the classes in that package and no other packages.
The Common Reuse Principle - The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.
The acyclic dependencies principle - Allow no cycles in the package dependency graph
Where can I find more information about these?
I totally agree that OO code can be expensive to write. However, I find the big payoff not to be in development time, but in reliability. For me, OO code is easier to test and maintain.
Well if it's doing those things then it should be saving you time. The thing I was trying to do was generalize to the point that I'd achieve high level reusabilty. I was writing my own framework as I worked but I found that it couldn't be justified in a business sense. Basically this idea people have about writing their own frameworks is a bit wank. You won't save time by doing that.
arborint wrote:Because you are complaining about problems most people accept but that zealots argue about.
I'm thinking about it now in heignsight, I've wasted a lot of time, I think it's important I consider why.
As to your reuse problems, it is not clear whether you are any different that me -- except that you have higher expectations. I do get a fair about of reuse from my codebases, but that is more form getting similar problems to solve. Continuous upgrading is still a problem though.
Well the annoying thing is, as I outlined in my original post, there are probably ways to achieve what I want to achieve but it required more knowledge and experience on my part and the certain technologies need to mature a bit.
sike wrote:my current strategy is to get the project done and generalize only parts of my code base if i see similarities from previous projects (aka harvested frameworks). this works out ok thus far but i have to admit that the resulting "framework" is more of a library of building blocks for most of the projects i do.
Yes, I think this is what I should be doing. Well, that was my initial intention and then you read back the code and go "oh I can remove a dependency here" and "i'll improve the interface here" and before you know it you are spending weeks generalizing.