In this course, you'll explore the basic structure of a web application, and how a web browser interacts with a web server. You'll be introduced to the request/response cycle, including GET/POST/Redirect. You'll also gain an introductory understanding of Hypertext Markup Language (HTML), as well as the basic syntax and data structures of the PHP language, variables, logic, iteration, arrays, error handling, and superglobal variables, among other elements. An introduction to Cascading Style Sheets (CSS) will allow you to style markup for webpages. Lastly, you'll gain the skills and knowledge to install and use an integrated PHP/MySQL environment like XAMPP or MAMP.
Bonus: Rasmus Lerdorf - Inventing PHP
Loading...
来自 University of Michigan 的课程
Building Web Applications in PHP
956 个评分
从本节课中
Introduction to PHP
We begin learning PHP.
与讲师见面
Charles SeveranceProfessor
School of Information
[MUSIC]
All right, so it started in 1993, when I saw the Mosaic web browser.
That was when I got really interested in the web.
I had been doing Gopher and IRC and other Internet-related things before then.
But with Mosaic, I could suddenly explain what I was doing to my mother.
So I knew this thing was going to be very, very interesting.
I was living at Mountain View, California,
but I moved back to Toronto to do consulting.
And I ended up consulting for a number of companies and
I wrote the same code over and over.
Basically CGI scripts is written in C.
And I wrote similar codes with handle forms and post data and filtering.
And all those sort of common web things you end up having to write in C
if you're writing raw CGI programs.
So, that was getting tedious.
I'm not very interested in programming.
It's kind of tedious and boring.
So if I could reduce the amount of time I had to spend programming and maximize
the output and get to the solution quicker, that was my goal with PHP.
I put together all my common stuff into a C library.
Hacked into the NCSA web server.
And then added a little templating system on top of that to let me easily call
into it.
And that was the first version of PHP.
It was a productivity tool for myself, so
I could very quickly go to a new client and whip up a new web application for him.
And tie them to the database or whatever they needed needed.
And every client had slightly different requirements, so I kept extending my tool.
Then other people started asking me about this stuff.
They asked me how I built these things, and I said, well,
I'm using this little tool I built.
And they asked if they could have it, I was like, sure, why not?
That's not what I'm selling.
I'm selling my services of solving problems.
The tool itself is irrelevant really.
It's just my hammer, and anybody can use my hammer, I don't care.
And then they started sending me patches, which I thought was really, really cool.
And they found bugs in my stuff that I hadn't found yet,
which meant I could also go into clients and say, hey, here we go.
Here's a new version that fixes this, this, and this.
And they thought I was being extremely productive, writing all this code and
fixing all these things so fast.
So, that's when open source really hit me.
This was in 1994, 1995 before the term open source existed.
But it really caught on with me that I got together with a group of my peers.
Other people interested in the web,
solving the web problem from all around the world.
We all had similar problems, we faced similar issues.
And collaborately, we could build a tool that solved this problem.
And that was really how PHP got off the ground.
I learned a bit along the way, that in order for this to grow,
I had to give up control of PHP.
We had to let other people have some control.
I couldn't rewrite everybody's patches both because I'm pretty lazy and
it's a lot of work.
But also to give people some ownership in the project.
Once they have some ownership, once they have full control over their part of it,
then they become much more invested in it.
And they become passionate and it becomes theirs.
Not just them contributing to my project, it becomes our project, and
that really changed the nature of PHP.
That happened around 1997 or so, where I really delegated it out and gave people
full access to the CVS repository that I was using to develop the stuff in.
And it grew like crazy after that.
Both because the web grew and PHP was sort of in the right time, the right place.
But also because it was very, very easy to get in and
to get started contributing to PHP and using PHP, as well, obviously.
It has a very low barrier of entry.
So both on the using PHP side, and also contributing to PHP side,
I tried to keep the barrier to entry really low.
It does not take much, even today, to get a CVS account and a PHP project.
Source provision control is a wonderful thing.
It doesn't really matter how bad the initial patch is from some contributor.
We can always fix it.
Much rather welcome new contributors and guide them along, get them to be
productive and useful than yell at them for having a bad initial patch.
>> From the outside, you look like a well oiled machine.
And it's a well oiled machine
that accomplishes things more effectively than a commercial organization.
But at the same time, it's a band of brothers to some degree.
>> We have close to 1,400 people with CVS accounts,
which means those people can all commit to some part of the repository.
Either PHP, PEAR, PECL, the documentation tree, anywhere in there.
Now they're not all active, obviously.
We probably have maybe slightly over half
the people have committed something in the last year and a half.
There's no management of these people really.
They sort of self-organize into smaller groups.
It's impossible to manage 1,400 people, obviously.
Especially when they're volunteers and they're not actually
going to show up to a meeting or to a meet and greet or email or whatever.
But they self-organize around what they're interested in.
So we have documentation teams for the various languages.
There's a big French documentation team that just worry about the French
translation of the documentation.
There's a Japanese translation team.
Big group of core documenters.
And those guys organize themselves.
There's no big chief of this whole thing.
I don't tell people what to do, I can't.
They're not going to listen to me.
Why would they listen to me, right?
They do what they're interested in, that's the only way volunteers work.
Then there's the PECL guys that build PECL extensions.
Generally, that's sort of where we test out new extensions and
bring in certain ones.
Like in PHP 5.1, we brought in the JSON extension, which started its life in PECL.
Next, maybe or some of the others that are big right now.
So that's sort of how new features and new things eventually creep in.
They live outside of the core tree, and they get enough penetration there,
enough people install them.
We see Linux distros pulling them in,
in their core version of PHP they pulled in some of these things.
So we sort of look at what's happening out there.
And that happens, but there's no real management of that either.
And it's a meritocracy, code speaks.
If you write a patch or
you write a piece of code to implement the feature, that says a lot.
If someone wants to disagree with that way of doing, if they can offer
an alternate implementation, that's a really good argument.
If all they do is whine about it, that's a really bad argument.
And chances are that the implementation will win.
Even though it may not be the best way of doing things, there is code,
it sort of works.
That's what we go with, and that's always been the default.
It doesn't always lead to consistency.
But it does lead to getting the features and actually being able to do something.
Being able to connect with this type of database,
even though it may not be the best way of doing it, at least it gets you there.
And that's always been what PHP is about, is solving the problem.
We'd rather have an ugly feature than not having a feature at all.
[MUSIC]
