[UPHPU] notes from austin php users group

[John David Anderson]

On Dec 19, 2006, at 11:19 AM, Joshua Simpson wrote:

> On 12/19/06, jtaber <jtaber at johntaber.net> wrote:
>
> It's not what PHP needs, it's what companies/developers need.
> Especially in a climate where excellent programmers are few and far
> between.  Thus, good frameworks speed development, ensure standards,
> reduce errors, and reduce maintenance.
>
> I guess it depends on your personal definition of the word  
> 'framework'.  To me, it's come to symbolize a bloated, overextended  
> set of tools that often imitates the authors' personal preferred  
> language's (Java, C++, etc) that often detract usage or hide  
> features of the native language.

Yeah, that's how.... wait. No, that's not it.

By framework, I mean a pile of code that comprises all the stuff you  
need to put in 90% of the applications you build - thus enabling you  
to cut to the chase rather than reinventing the wheel each time you  
sit down to a new project. Well, that, and the code is tested by  
thousands of people on varied environments, many of which contribute  
free code and ideas to the said pile of code.

> Of course, if you mean 'a collection of libraries utilized for one  
> specific purpose', then I certainly agree.

libraries != framework (re: Zend "Framework")

> Of course, extracting and removing boilerplate code, custom  
> exceptions / error handling, automation, and sometimes unit testing  
> is par for the course for any good development team. And, often,  
> internally developed (if done correctly) frameworks will result in  
> just as much (if not more!) reduced development time, debugging,  
> maintenance while ensuring standards.  Also, you don't have to deal  
> with learning Yet Another Framework (tm), which can be just as hard  
> as learning a new language (and counterintuitive to good said  
> language's developers).

I don't mind internal frameworks or libraries, though they miss out  
on community based advantages (free code, free testing).

> It takes time and talent to learn a foreign, bloated framework, too.

Yes, but 10 hours spent mastering something in trade for hundreds of  
hours saved otherwise has been my personal experience. Not to mention  
all the untold hours others have spent testing and writing components  
that I never had to.

> If you spent your time reusing your own team's 'framework', you 1)  
> grow as developers in the process, 2) get exactly what you want, 3)  
> and don't have to rely on an outside team to get what you want.  Of  
> course, you can always modify the framework to suit your own  
> ideals, but doesn't that defeat the process?

Assuming that the framework you "modify" isn't extensible, yeah. I  
don't think I'd use one that isn't though. MVC setups are really  
modular and extensible by definition, so I don't experience any sort  
of lock-in you're talking about. There's a smart way to modify, and  
many such modifications might already be available though the  
community already anyway (unless they are extremely specific).

Making custom changes doesn't defeat the purpose - that *is* the  
purpose. You're only going to need to write code that performs logic  
specific to your application.

> If during your development time you slowly developed your own, you  
> probably would've saved a lot of time spent trying out and learning  
> various frameworks (and, in the end, be much more satisfied).

Sure, but again, you miss out on the community benefits. And, in a  
sense, you've recreated your own wheel you can use over and over,  
rather than just grabbing a free one off the shelf.

-- John

aka _psychic_