True that there is additional maintenance, and documentation required. Which I believe is worth it. However I would argue that I and many developers in the past have tried to force a single platform/language/db etc. The reality is we (and our clients) cannot afford to rewrite everything using our new favorite tool of the year. Especially when there are other tools that already do a better job at it than what we might put together giving the time, cost, minimal requirements etc. Some clients may want a all in one and have the money to pay for and be willing to wait long enough for the code to be completed. I just haven't found any of those clients yet.
I've picked what at the time seemed to be the best software in its market space for a specific subsystem. Learn how to use it well. On occasion if the tool is lacking a requested feature I would re- evaluate the available options and switch my preferred tool for that subsystem. Having an integrated layer also means we can swap out that subsystem if something better suited comes along. And this I believe is the proper way to keep a large system migrating to newer tools. I agree this has been a good discussion and I don't think there is a right or wrong way to answer and solve the problem, as a matter of fact I think each situation needs to be evaluated and analyzed. I do the same thing when I'm setting up a new physical network, I use a certain brand and class of hardware on all my installs. I know the interfaces well and I am familiar with the hardwares faults. At some point we as a development community started looking back at what we've tried and what works best. Often we've found what we thought was the best way to do something was completely wrong. The Gang of Four did this best. A process we should all continue to do is a self evaluation of our efforts and their results. Have a great day Coding today! On Sep 14, 11:58 am, "j.blotus" <j.blo...@gmail.com> wrote: > Lunar, your approach sounds good in the sense that it will get you up > and running quickly (other than having to learn how to use some new > piece of code and dealing with those bugs), but from all the patching > together it sounds like a maintenance nightmare! Thanks for the > insight though this tread as been quite interesting and helpful. > > On Sep 14, 1:02 pm, LunarDraco <mdc...@gmail.com> wrote: > > > If you want to really do anything with cake and a blog system, I would > > say your best effort would be in learning how to integrate and use an > > existing blogs API > > > For my clients I'm usually being asked to solve a problem. More often > > than not that problem is an integration problem between already > > implemented and heavily used systems. I need to bring a business > > concept together which often includes payment options, blogging, > > email, graphs, maps, OpenID, etc a whole slue of subsystems which > > already exists. You'll have a more complete toolbox if you learn how > > to properly use and integrate with these other systems via their > > published API's. This activity of learning to use an API from within > > cakephp will cover two aspects being discussed. It will give you the > > opportunity to learn and practice writing cakephp apps, plugins, > > behaviors, components, and helpers. And at the same time give your > > cakephp app access to some really complete subsystems like WordPress, > > Google Maps, Google Analytics, Annotated Time line, PayPal, > > QuickBooks, etc. > > > Anytime you can use the resource of hundreds of other developers to > > help you build your system I'd take full advantage of that. > > I use cakephp, sql, php, crons etc to glue all the other subsystems > > together into one cohesive system of applications for the client. I > > write what I can't find or when the tools I do find do not provide a > > clean way to integrate or are just to difficult to modify to the > > clients needs. I have web apps that are a mix of servers Linux, > > Windows, and seamlessly integrate between apache and IIS with mixed > > dbs of MSSql and MySql. From the users point of view they are in one > > app. > > > I really believe our industry has leaped past the one off apps. We > > don't build apps anymore, we integrate, build and organize systems. If > > you do build a one off app, I'll guarantee you the first request your > > client will ask is can we integrate this with our xxxx system/app? > > I love cakephp because its structure allows me to integrate, build and > > use these other systems. A few of my cake apps are never viewed by > > human eyes, they run as cron/shell apps to move data between systems > > that don't know how to work together. The Model Controller layers > > accompanied with a few components like task queue and some crons makes > > cake a great way to add background functionality to legacy systems. > > I'm still a one man team, but that is only possible because I use > > systems that are actively supported by many hundreds of developers and > > community members. > > > You can't go wrong in learning how to integrate and use these other > > subsystems. By doing so you add a lot of functionality to your toolbox > > with very little effort. At least a lot less effort than rolling your > > own. Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
