Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #10678 > unrolled thread

Learing PHP, Javascript, and Python on the Cheap, Help!

Back to article view | Back to comp.lang.php

Contents

  Learing PHP, Javascript, and Python on the Cheap, Help! irishhacker@gmail.com - 2013-08-31 08:52 -0700
    Re: Learing PHP, Javascript, and Python on the Cheap, Help! Fiver <numeralfive@gmail.com> - 2013-08-31 18:36 +0200
    Re: Learing PHP, Javascript, and Python on the Cheap, Help! "J.O. Aho" <user@example.net> - 2013-08-31 18:37 +0200
      Re: Learing PHP, Javascript, and Python on the Cheap, Help! Twayne <nobody@spamcop.net> - 2013-08-31 14:57 -0400
        Re: Learing PHP, Javascript, and Python on the Cheap, Help! Jimmy Brubaker <jimb21@owandslow.com> - 2013-09-18 18:46 +0000
      Re: Learing PHP, Javascript, and Python on the Cheap, Help! The Natural Philosopher <tnp@invalid.invalid> - 2013-08-31 20:01 +0100
    Re: Learing PHP, Javascript, and Python on the Cheap, Help! The Natural Philosopher <tnp@invalid.invalid> - 2013-08-31 19:57 +0100
    Re: Learing PHP, Javascript, and Python on the Cheap, Help! Twayne <nobody@spamcop.net> - 2013-08-31 15:31 -0400
    Re: Learing PHP, Javascript, and Python on the Cheap, Help! Jerry Stuckle <jstucklex@attglobal.net> - 2013-08-31 16:21 -0400

#10678 — Learing PHP, Javascript, and Python on the Cheap, Help!

I want to practice Javascript/HTML/CSS and the server side (PHP & Python) on the cheap, which means I want both the client and the server to be on the same hard drive. (My setup is Ubuntu Linux). I'm not sure what is already installed (Python and Perl was installed with the Ubuntu.)
How do people usually do that? And once they do that, later on, how difficult is it to transition where the server code (PHP/Python) is on a remote server? I'm hoping that the transition from hard drive to remote server would involve 99.9% of the PHP/Python code still working.

Obviously, that setup makes it difficult to test for Internet Explorer special annoyances and for high-level performance testing, and I'll live with that.

Thank you.

[toc] | [next] | [standalone]

#10681

On 2013-08-31 17:52, irishhacker@gmail.com wrote:
> I want to practice Javascript/HTML/CSS and the server side (PHP &
> Python) on the cheap, which means I want both the client and the server
> to be on the same hard drive. (My setup is Ubuntu Linux). I'm not sure
> what is already installed (Python and Perl was installed with the Ubuntu.)
> How do people usually do that? And once they do that, later on, how
> difficult is it to transition where the server code (PHP/Python) is on a
> remote server? I'm hoping that the transition from hard drive to remote
> server would involve 99.9% of the PHP/Python code still working.

It's not difficult to set up at all. Everything you need is either
already installed or can be easily installed from the repository.
Chances are that you already have a local Apache web server installed,
maybe PHP, too. If not, install the libapache2-mod-php5 package with
your package manager of choice (I think the default on Ubuntu is
Synaptic; on the terminal you can use aptitude or apt-get). This package
and its dependencies will install and set up everything you need to get
started. Just point your browser at http://localhost/ and code away. The
default document directory is /var/www.

Transitioning to a remote server: that's not enough information. Will
the remote server use the same OS? The web server (Apache)? The same PHP
version and configuration? Will there be a database? Deploying a local
project remotely can be as simple as copying the files over, or you may
have to make some adjustments and maybe use (or write) a custom
deployment method. The more complex a project is, the more effort will
have to go into deployment and dependency management, but if you're just
starting out, I wouldn't worry too much about it.

When you're familiar with the environment, there are two more
non-essential things you should set up before you start a project:
version control (Subversion, Git, etc) and a separate local Apache
virtual host for the project you're planning to deploy remotely. This
will make managing multiple installations easier in the long run.

> Obviously, that setup makes it difficult to test for Internet
> Explorer special annoyances and for high-level performance testing, and
> I'll live with that.

There are ways around that. You can test from another computer, or use
something like BrowserStack, or run Windows locally in a virtual machine
(install the "virtualbox" package). Microsoft offers various free
virtualization guest OSs for testing purposes, see
<http://www.modern.ie/en-US/virtualization-tools>.

regards,
5er

[toc] | [prev] | [next] | [standalone]

#10682

On 31/08/13 17:52, irishhacker@gmail.com wrote:
> I want to practice Javascript/HTML/CSS and the server side (PHP & Python) on the cheap, which means I want both the client and the server to be on the same hard drive. (My setup is Ubuntu Linux). I'm not sure what is already installed (Python and Perl was installed with the Ubuntu.)
> How do people usually do that?

sudo apt-get install apache2 php5 libapache2-mod-php5 mysql-server 
mysql-client php5-mysql

that will install all you need to get things to work. There are quite 
many "HOWTOs" for ubuntu, some worse than others, google will find them 
for you.

You may need to configure things to your taste.

I do recommend usage of git for version control of your code.


> And once they do that, later on, how difficult is it to transition where the server code (PHP/Python) is on a remote server? I'm hoping that the transition from hard drive to remote server would involve 99.9% of the PHP/Python code still working.

To be sure things works in your development environment and live 
environment is to have as similar setup and use the same extensions and 
settings.


> Obviously, that setup makes it difficult to test for Internet Explorer special annoyances and for high-level performance testing, and I'll live with that.

Who cares about MSIE, things do not work the same way between minor 
version changes and badly documented how they work. Just use some 
framework like twitters bootstrap and then keep it simple, if it work 
with MSIE then it works with MSIE, if it don't let the end user pick a 
better browser.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#10685

On 2013-08-31 12:37 PM, J.O. Aho wrote:
> On 31/08/13 17:52, irishhacker@gmail.com wrote:
...
>
>
>> Obviously, that setup makes it difficult to test for Internet Explorer
>> special annoyances and for high-level performance testing, and I'll
>> live with that.
>
> Who cares about MSIE, things do not work the same way between minor
> version changes and badly documented how they work. Just use some
> framework like twitters bootstrap and then keep it simple, if it work
> with MSIE then it works with MSIE, if it don't let the end user pick a
> better browser.
>
>

I'm afraid I have to refute the wisdom of simply ignoring IE users; 
unless the audience is small, well known, and prone to using other 
browsers, it's bad advice as it will just make people think the author 
is a dummy.
    Take two of my websites: One is a website for graduating class 
reunions, and the other a general audience website with over a k of 
hits/day.
    Statistics show a very high percentage of visitors using IE, slowly 
dwindling from IE 8 and 9, to IE 10, using simple analytics software.
    Because IE won't handle it, what makes you think the myriad other 
browsers available will handle it? So, just because someone uses IE, 
pissing them off would be foolhardy. A site exists FOR it visitors, not 
the other way 'round.
    IE and FF are by far the leaders on my sites, overall, with IE 
having the top numbers, FireFox, some Safari, a few Chrome, and a couple 
others I never heard of that might be simple spoofs. There are more, but 
I seldom look at the 1%'s or less. And o'seas, it's practically 100% IE, 
so market audience matters.

Regards,

Twayne`

[toc] | [prev] | [next] | [standalone]

#10802

Twayne wrote:

>     Statistics show a very high percentage of visitors using IE, slowly
> dwindling from IE 8 and 9, to IE 10, using simple analytics software.

Or faking it for compatibility reasons.

[toc] | [prev] | [next] | [standalone]

#10687

On 31/08/13 17:37, J.O. Aho wrote:
> if it work with MSIE then it works with MSIE, if it don't let the end 
> user pick a better browser.
>
Or a better website than yours.

I had a general rule. If the site didn't work with my browser I found 
the product I wanted  on one that did.

Those sites are now gone. One hopes their coders are also out of work.  
That's probably where Jerry Stuckle comes from.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10686

On 31/08/13 16:52, irishhacker@gmail.com wrote:
> I want to practice Javascript/HTML/CSS and the server side (PHP & Python) on the cheap, which means I want both the client and the server to be on the same hard drive. (My setup is Ubuntu Linux). I'm not sure what is already installed (Python and Perl was installed with the Ubuntu.)
> How do people usually do that?

install apache and php and maybe mysql. It is relatively trivial to get 
a server running.

> And once they do that, later on, how difficult is it to transition where the server code (PHP/Python) is on a remote server?

more or less indentical., with te proviso that server farms may hand you 
a slightly different version/configuration

> I'm hoping that the transition from hard drive to remote server would involve 99.9% of the PHP/Python code still working.
valid assumption.
> Obviously, that setup makes it difficult to test for Internet Explorer special annoyances

no. run virtualbox and an ageing copy of IE6/XP in it like wot I do..
>   and for high-level performance testing, and I'll live with that.
actually when it comes to e.g fine tuning mysql queries for speed its 
the better test bed. The only difference is you have massive bandwidth 
locally, but that is just a question of keeping data sizes as low as 
possible

> Thank you.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#10689

On 2013-08-31 11:52 AM, irishhacker@gmail.com wrote:
> I want to practice Javascript/HTML/CSS and the server side (PHP & Python) on the cheap,

which means I want both the client and the server to be on the same hard 
drive.

(My setup is Ubuntu Linux). I'm not sure what is already installed 
(Python and Perl was installed

with the Ubuntu.)
> How do people usually do that? And once they do that, later on, how difficult is it to transition

  where the server code (PHP/Python) is on a remote server? I'm hoping 
that the transition from

hard drive to remote server would involve 99.9% of the PHP/Python code 
still working.
>
> Obviously, that setup makes it difficult to test for Internet Explorer special annoyances and for

high-level performance testing, and I'll live with that.

Should not ever be a problem with clean code. You'll spend likely more 
time learning about Security in PHP and Python than most of the rest of 
it. I don't know what you mean by "special annoyances" unless it's 
quirks mode or something like that. And as for performance testing, 
that's done on the server, not on the browser.
>
> Thank you.
>

Those are good objectives and some pretty long learning curves but it'll 
be well worth it when you've got most of it under your belt and your 
research method in tune with the effort.

I don't use Linux and have only dabbled in it so I can't speak to that 
at all. However, I don't think the basics are any different than with 
any other OS. Anyway, I can't speak to Linux apps et al but I can 
respond to other things.

1. There should be no problem IME having both client and server on the 
same disc. My local server, clients, browsers et al all live on the same 
disk with their "junk" offloaded to another disc drive for easy control 
and to minimize the mess on the boot drive.

2.  Transitioning to a remote server is simple and no problem at all. 
Of course you need to be certain the remote server offers PHP (and that 
is the version of PHP you should use, to avoid deprecations and such), 
and that it offers Python also, in the same vein as PHP.

3. Once the local and remote servers are both running equivalent 
versions of PHP, ASP, PERL, Python, etc., it's a simple matter of 
setting NOF's Remote ftp settings proper and telling it to Publish to 
your remote site. Most remote servers can handle PHP versions 4 or 5, 
but Python, well, not so much; be sure you check it out. Usually a 
php_info.php is all you need to get a full listing of information about 
your account.

4.  So, transitioning from local to remote servers is almost a 
no-brainer once you set NOF's ftp settings properly.  The only real 
thing you need to know is your "root" directory on the server 
(public_html, html, and a few other possibilities) and NEVER upload to 
anything higher than your root directory; everything goes in, or under, 
that directory.
    There are some very rare occasions where you might want to use a 
separate ftp program like FileZilla, ws_ftp, etc., to upload files. I do 
it myself on occasion and have no problems, but NOF makes it a gazillion 
times more efficient to accomplish.

BTW, 99.9% working is NOT at all acceptable: It has to be 100%. 1 wrong 
character out of ten thousand or a million lines of code is enough to 
trash the entire operation of the script sometimes; that's why local 
servers with matching versions of the apps on the remote server helps 
immensely.

I think you're in for some pretty interesting and likely frustrating 
issues to meet your goals, so it'd be best to accomplish them one at a 
time rather than all at once, to keep trouble-shooting easier. Assuming 
you are already grounded in HTML, take PHP next. I'm not sure what you 
would do with Python code, but best of luck with it.

In case you're not already aware of them, php.net and w3schools.org are 
the best two "bibles" for html, CSS, php, and several other languages 
too. Oh yeah: don't forget CSS either 2 or the latest is 3. I just 
noticed you didn't mention CSS (cascading style sheets).

Regards,

Twayne`

[toc] | [prev] | [next] | [standalone]

#10690

On 8/31/2013 11:52 AM, irishhacker@gmail.com wrote:
> I want to practice Javascript/HTML/CSS and the server side (PHP & Python) on the cheap, which means I want both the client and the server to be on the same hard drive. (My setup is Ubuntu Linux). I'm not sure what is already installed (Python and Perl was installed with the Ubuntu.)
> How do people usually do that? And once they do that, later on, how difficult is it to transition where the server code (PHP/Python) is on a remote server? I'm hoping that the transition from hard drive to remote server would involve 99.9% of the PHP/Python code still working.
>
> Obviously, that setup makes it difficult to test for Internet Explorer special annoyances and for high-level performance testing, and I'll live with that.
>
> Thank you.
>

Not hard at all.  J.O. gave you the instructions to install the required 
packages.  From there on, careful programming and attention to the 
settings should allow your code to transfer to a hosting company with 
very few changes.

You will probably want to add your own VirtualHost to your Apache 
configuration; there is a default one but you'll probably want your own 
options.  I suggest you start with the default one, but read up on 
VirtualHost and the various options in the Apache configuration (the 
folks in alt.apache.configuration can help you here).

You can access the server locally via http://127.0.0.1 for the default. 
  If you want your own server name for testing (i.e. example.com), you 
can set a VirtualHost for it in the Apache configuration and add an 
entry to your /etc/hosts file for the name, pointing it at 127.0.0.1 
(you will also need this if you use the non-default VirtualHost in the 
Apache configuration).

Some things to keep in mind:

1. Ensure you have the same PHP settings as the server, as others have 
indicated (or at least have compatible settings).  There are multiple 
hosting companies out there; if you find one which is incompatible, look 
for another one.  I've found usually the default options set by Debian 
work well; since Ubuntu is based off of Debian I would think the options 
are similar (or identical).

2. Don't hard code the server name in your scripts.  If you need to use 
the server name (most of the time you don't), use $_SERVER['SERVER_NAME'].

3. All file system paths in your scripts should be relative to 
$_SERVER['DOCUMENT_ROOT'].  Don't code any absolute paths in your scripts.

4. Put anything else system specific - i.e. database names and 
passwords, in a configuration file (i.e. config.php).  These will have 
to change when you go to a hosting service, so keep them together.  And 
put this file (and any other information you want to keep private) out 
of reach of the web - this is usually one level above the DOCUMENT_ROOT.

You will be able to get a good idea (but not perfect, obviously) if your 
scripts will work by just moving everything to a new directory hierarchy 
and changing the VirtualHost entry (including the server name) and 
updating your /etc/hosts file.

I do a lot of development on my local systems here, then upload the 
files to the server.  Other than the items in #4 above, everything 
transfers and runs with no changes.  But if I'm working on a client's 
files, I ensure my test system has the same options as the client's 
hosting company.

I probably forgot something, but can't think of what it might be right now.

Hope this helps some.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web