php-general Digest 4 Jan 2010 09:51:32 -0000 Issue 6520
Topics (messages 300787 through 300791):
Re: Instll php on Window 2003 64Bit questions
300787 by: Daniel Egeberg
300791 by: Richard Quadling
Re: If design patterns are not supposed to produce reusable code then why use
them?
300788 by: Tony Marston
300789 by: tedd
300790 by: Daniel Egeberg
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Sun, Jan 3, 2010 at 08:10, Edward S.P. Leong <edward...@ita.org.mo> wrote:
> Dear All,
>
> If the OS is Windows 2003 64Bit (IIS)...
> So, which php package must download and how to config it for running
> with IIS ?
> Due to I don't quite the online manual:
> http://www.php.net/manual/en/install.windows.iis.php
> Which installation mode is suitable of it ?
>
> Thanks !
>
> Edward.
Do you mean which of the two IIS installation guides in the manual you
should follow? IIS7 is from Windows Vista (or Windows Server 2008) and
up, so you would have to go with the first link. So you can download
the PHP 5.3.1 VC9 non-thread-safe build from http://windows.php.net
and follow the steps in
http://www.php.net/manual/en/install.windows.iis6.php.
--
Daniel Egeberg
--- End Message ---
--- Begin Message ---
2010/1/3 Ashley Sheridan <a...@ashleysheridan.co.uk>:
> On Sun, 2010-01-03 at 15:10 +0800, Edward S.P. Leong wrote:
>
>> Dear All,
>>
>> If the OS is Windows 2003 64Bit (IIS)...
>> So, which php package must download and how to config it for running
>> with IIS ?
>> Due to I don't quite the online manual:
>> http://www.php.net/manual/en/install.windows.iis.php
>> Which installation mode is suitable of it ?
>>
>> Thanks !
>>
>> Edward.
>>
>
>
> Personally I'd go with a WAMP install instead. Apache is faster, less
> resource intensive, and more secure than IIS. You also have the benefit
> of all the Apache mods out there, like mod_rewrite, which I believe
> you'd have to pay for on an IIS server.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
IIS7 has a URLRewrite module which is freely available via the Web
Platform Installer or via
http://learn.iis.net/page.aspx/460/using-url-rewrite-module
--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
--- End Message ---
--- Begin Message ---
"Larry Garfield" <la...@garfieldtech.com> wrote in message
news:201001010553.41956.la...@garfieldtech.com...
> On Friday 01 January 2010 05:26:48 am Tony Marston wrote:
>
>> > It depends what you're reusing. Design patterns are reusable concepts,
>> > not reusable code. That's the key difference.
>> >
>> > Knowledge of design patterns is like knowledge of how different food
>> > ingredients interact. "Hm, this needs something to bring out the taste
>> > more,
>> > so I'll add salt." You're not going to add the same salt to each dish,
>> > obviously, but the idea is that you need something that will bring out
>> > the taste, and there are certain spices that will bring out the
>> > existing
>> > taste of
>> > whatever it is you put them on, such as salt.
>>
>> Food recipes are a bad analogy for design patterns. A food recipe
>> explicitly identifies a list of ingredients and a list of actions which
>> are required to produce the intended result. The design pattern
>> equivalent
>> of a recipe would simply state "take a bunch of ingredients, mix them up,
>> heat them up, serve them up". A design pattern merely identifies the
>> concept, not the
>> implementation, so where is the REAL benefit? Where is the re-usability?
>
> Note that I did not say that design patterns are a recipe. I said they're
> knowledge of how different foods interact. They're meta-knowledge that
> makes
> you a better chef, not a faster short-order cook.
Knowledge of how foods interact will not in itself make anyone a good cook.
Knowledge of design patterns will not in itself make anyone a good
programmer. It is how that knowledge is applied which makes the difference.
The problem with design patterns is that the actual implementation is left
up to the indvidual, and if the implementation is faulty the fact that a
design pattern was used is nothing more than a red herring.
>> > Similarly, if you want, say, a piece of code that will connect to a
>> > database, you want a pre-built library, not a design pattern.
>> > (There's no shortage of
>> > those.) If, however, you want a mechanism by which you can have
>> > different implementations of the same system, and want to swap them out
>> > without rewriting the calling code, then what you want is the factory
>> > *pattern*. There may not be existing code yet for whatever system
>> > you're
>> > writing. However, once you recognize "Ah, I want a common interface
>> > with
>> > a swappable implementation, and I want to pick the implementation at
>> > runtime based on some arbitrarily complex logic", then you know you
>> > don't
>> > need to think through how
>> > you go about structuring the code to do that. Instead, you look up a
>> > description of the factory pattern and go "ah, that makes sense, and it
>> > solves 3 problems that I didn't realize I'd run into later". Then you
>> > go and
>> > implement code that follows that pattern, and you don't have to think
>> > through the algorithm.
But the problem is that you DO have to think through the algorithm as a
design pattern exists just as a vague outline, a description of a possible
solution, not a workable solution that you can just plug in and go.
>> I would not use the factory pattern for such a thing. I have actually
>> written an application which can switch between database engines - MySQL,
>> PostgreSQL and Oracle - simply by changing a single line of code.
>> Although
>> I *could* use the factory pattern, in my experience it would be overkill
>> and too complicated.
>
> Oh really? I've written such a DB abstraction system as well. (I think
> most
> people have at some point.) Although I did not specifically go into it
> saying
> "I will use a factory for this", in practice it really is. Some client
> code
> says "hey, I need a DB connection, gimme!", an intermediary piece of code
> figures out which DB connection you need (based on configuration data,
> what
> servers are available, or whatever), and passes back a PDO connection
> object
> on which you run queries. That's a factory, in a nutshell. I suspect
> your DB
> abstraction system works on the same general principle.
>
> Yes, you're already using common design patterns, I wager, even if you had
> to
> "invent" them yourself.
I may be using constructs which have proved to be efficacious in my many
years of experience, but I do not look at my solutions using the vocabulary
of design patterns as the vocablary is too wishy-washy, too vague, too much
theory and too little substance.
> However, by understanding it AS a factory pattern, you can explain how it
> works to someone else through a common vocabulary. You can also look at
> your
> implementation and see where it's going to be extensible and where it's
> not by
> comparing it to similar approaches that have already been tried and
> vetted.
>
> The savings is in going "oh, hey, this approach to my problem has already
> been
> tried, and what I was going to do would have broken here, here, and here.
> But
> by following this similar approach, I can avoid those problems and spend
> less
> time rewriting code later".
>
> Yes, I have in fact run into that situation myself on more than one
> occasion.
>
>> The very idea of a "factory factory" fills me with nausea. I have seen
>> several examples and my immediate response has always been "real
>> programmers don't write code like that". Yet too many programmers are
>> taught that they MUST use design patterns, so they follow blindly
>> without
>> any regard for the consequences.
>>
>> Tony Marston
>
> "Real programmers" don't make jibes about what "real programmers" do out
> of
> ignorance.
The why is it that my critics always say that "real programmers use design
patterns" and that if I don't then I cannot be a "real" programmer?
> Yes, always blindly following a given design pattern for the sake of
> following
> a design pattern is stupid. Blindly ignoring established "solved
> problems"
> just for the sake of avoiding those pointless design patterns is just as
> stupid.
But design patterns do not provide workable solutions, they provide outlines
for possible solutions which you then have to build yourself.
> Remember, code is irrelevant. You don't sell code. You sell ideas and
> concepts, implemented in code.
But surely if the implememnation is bad then the concepts are irrelevant.
Just because an application has been designed using all the "correct" OO
concepts and built using every design pattern ever conceived does not mean
that it will be a success. I was actually involved in a system just like
that, and I can report that it was a total disaster. It may have been used
all the right buzzwords, but it was still crap.
> By not having to re-invent the ideas and
> concepts every time, you can save a great deal of time and effort, and
> potentially a great deal of code that you don't need to rewrite later from
> going down a dead-end.
But if you have to spend time researching which pattern (or combination of
patterns) sounds like that it may be a match for your current problem, then
you have to build the code yourself from scratch, where exactly is the
saving? An experienced programmer does not need to know the name of the
pattern he is implementing in order to write good code. Just because an
inexperienced programmer does know the name of a design pattern does not
mean that his implementation will be correct.
> There's two kinds of developers: Those that understand how they're using
> design patterns and those that don't understand design patterns. :-) But
> both
> are, in practice, using them, even if some are doing so badly (either
> over- or
> under-using them).
>
> --Larry Garfield
I offer an alternative view - there are those programmers who need design
patterns to fill a hole in their experience, as a sort of mental crutch, and
there are those who do not need design patterns as they have the experience
and ability to work without them, just as an experienced cyclist does not
need training wheels, and an experienced artist does not need a
painting-by-numbers kit.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
--- End Message ---
--- Begin Message ---
At 5:16 PM +0000 1/3/10, Tony Marston wrote:
I offer an alternative view - there are those programmers who need design
patterns to fill a hole in their experience, as a sort of mental crutch, and
there are those who do not need design patterns as they have the experience
and ability to work without them, just as an experienced cyclist does not
need training wheels, and an experienced artist does not need a
painting-by-numbers kit.
--
Tony Marston
Tony:
I respect your opinion, but there may be more to this than what you said.
As some of you know, I've been pounding code since 1965 and while I'm
not the sharpest crayon in the box, I am seeing new things all the
time. Perhaps I'm seeing the same thing over and over, but while some
of this is rehashing old ideas and presenting them in new packaging,
some of it is actually new concepts worth investigating.
Clearly OOP is different than procedural code. Likewise, Design
Patterns (DP) are different ways to categorize problem solving than
relying upon personal experience. These two new camps (OOP/DP) are
similar in grouping as are the older procedural and experience camps,
if you get my meaning. These different camps are much like a light
switch, either you swing one way or the other, but not usually both.
I find myself in both camps and being somewhat overwhelmed by the
newer camp. The procedural/experience camp provides me with all the
tools I need to get anything done that I want done. Whereas, the
OOP/DP provides me with enough intrigue to prompt me to investigate
-- and the more I look, the better I like. There appears to be more
here than just an inexperience issue.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
I think it also to some extent comes down to having a shared
vocabulary. Pretty much the same way that you know which technique I'm
talking about when I use the word "recursion", which algorithm I'm
talking about when I say "quick sort" and which data structure I mean
when I say "linked list". It's way easier saying "quick sort" than
describing how the algorithms works each time. Yes, you may be able to
come up with a sorting algorithm yourself, but now when I tell you
that there is a sorting algorithm called quick sort you'll either know
which particular sorting algorithm I'm talking about, or you can go
look it up. Various implementations may for instance then employ
different sorts of optimizations to make it work well in one
particular scenario.
Design patterns are called patterns specifically because they are
things that happen to occur frequently in code, i.e. they are
recognizable patterns. It makes sense giving names to such things, and
they exist whether or not you name them of course.
There are a couple of reasons why a design pattern needn't necessarily
yield reusable *code*:
1) They transcend programming languages. A pattern may be implemented
in PHP, Python, Java, C++ or some other language, but particularly how
you would do it depends on which features and language constructs that
are available in the particular language.
2) A particular pattern may be applied to different problems. How you
would apply it depends on the nature of the problem. If we just use
the strategy pattern as an example, you may have different strategies
for an AI in a computer game, you may have different payment
strategies in an online shop and you may have different strategies for
calculating employees' salary. All of these three things are very
different in nature, but they may still use the same an overall shared
pattern that is then called "a strategy".
Tony, I disagree with your notion about design patterns being "mental
crutches". Besides for educational purposes, I see no reason why you
would want to spend time on rediscovering something that someone else
already discovered a long time ago. The point is of course not that
each time you need to do something you'll scour books and various
forms of online resources for a design pattern that fits exactly your
needs. The point is that by knowing these patterns, you'll know that
for a particular problem this particular solution tends to work well.
Indeed as you become more experienced, this will become more
transparent and "automated" so to speak.
You may very well discover or come up with some sort of pattern
yourself (though you might not necessarily give it a name), and you
may even unknowingly do something often that other people call a
design pattern and have given a name. Again, this is exactly the
reason why we call them patterns: they are things that people tend to
come up with, and they tend to work pretty well.
Now because there exists a sort of standard nomenclature, when someone
asks me how they should approach a particular problem I can tell them
to look up a particular pattern instead of trying to (re)explain it
when someone else has already done that in great detail.
I'm sure you can appreciate the benefit of having a shared vocabulary.
It's something that's going on in not just programming, but
practically in every field that exists.
I hope this makes some sense. It's my take on this anyway.
--
Daniel Egeberg
--- End Message ---
