I have a LAMP (Linux/Apache/MySQL/Php) application that I should release soon.
Even if I've never used it, I'm thinking about using autotools for it, to make the configuration and installation process easier (for the customer and for me, in the future).
Have you ever done (or thought) such a thing? Are there any drawbacks? Does it make a bit of sense?
Autotools is used mostly when you are trying to compile your programs for multiple target platforms. This applies for C code in general and checks stuff like available libs, size of data types, libc functions etc. So unless your program is written in C and you have a need for supporting all kinds of Unix flavors, dont bother with autotools.
If you are trying to build some kind of installation program for Linux, I suggest you look into rpmbuild (for redhat distros). Rpmbuild is easy to use if all you are doing is packaging files for easier distribution. A good tutorial is available here. One great aspect of rpmbuild is that you can specify requirements on the target system, for example: apache, mysql and even specific php-modules that you need.
For configuration and deployment, you can have a look at ant.
In my previous employment, we were using ant for deployment/configuration of a mix of perl, php, xml, xsl, unit test , Apache config ...
You have a build.properties file where you can put some default values and the customer will jsut have to create a local.properties where its values will overwrite the one from build.properties.
Also if you need to launch some scripts that are parts of the setup, you can also do that with ant.
simple idea
I may be stating obvious, but wouldn't it be easier for the sake of it, just to use
phpinfo();
?
From it you may mostly read everything - server version, PHP version, MySQL version and running PHP extension, compare it against what you need and advice to your client or their hoster that "I need this and that installed".
Related
I need to create a web application that tars files on a remote server then moves those files to another server. I am new to scripting languages and was wondering if there are advantages to php or perl for this type of application.
Not really. Both will get the job done just as good as the other. The bottleneck of both will be connecting to the remote server.
PHP was originally derived from Perl, so the syntax between the two are very similar. It's all a matter of taste.
PHP is nice because many Apache servers are setup to allow you to embed PHP code inside your HTML pages. This makes PHP very popular in building things like CMS systems and bulletin boards.
I personally think that the PHP syntax is sloppy. There's way too many specific functions and they're not clearly thought out. The syntax changes from one function to another. I guess it's part of PHP's group based philosophy where a lot of people add a lot of features. I also like Perl's use strict and use warnings pragmas which I find save me a lot of grief.
But, as I said, when it comes to webpage development, PHP is ahead of Perl.
(Yes, I know about modperl, but that's not usually installed in most Apache servers).
I'd say to go ahead and learn both. I believe the Perl books are some of the best written programming guides I've seen. I haven't been too thrilled with the PHP ones. Maybe its because Perl is just more established, so the documentation has been better defined.
Then again, if you're going to learn something, maybe you should try Python. I'm not a fan of Python, but its the up and coming language that most people are learning these days. Google uses Python extensively. And, don't forget Ruby which has the webbased Rails platform that's very popular.
By the way, what you want to do isn't part of the default language, but most languages have modules that are easily installable. For example, you'll need Archive::Tar and LWP for Perl. These can be downloaded from the CPAN module archive.
It's going to take you a while to pick up enough of any language to do what you want, so be patient and have fun.
You need this ssh extension http://php.net/manual/en/book.ssh2.php
It support calling ssh using ssh2_connect.
And you can bundle with tar, scp, or even rsync
I'm trying to understand the options and terminology relating to "installing" PHP libraries on a system (Linux/OSX)
Here are some specific points I'm trying to cover:
What does "install" mean when relating to PHP libraries?
What's the difference between libraries and extensions?
How does php.ini fit in?
How does PEAR fit in?
How do you import/include libraries?
If I create my own library, what's the best way to package and distribute it?
Thanks- and sorry for the multi-part...
A couple points...
PHP has no native "import" infrastructure, like python, java, or .net. There are several ways that libraries can be used in PHP.
compile them into the PHP binary. This is the most advanced way, and not usually desirable unless you have very special needs.
Install them as PHP modules on the server, and include them in PHP.ini. From the point of view of the PHP programmer, these extensions are part of PHP -- always available. It's just easier to add and remove them without having to rebuild PHP itself.
Install PHP code on the server somewhere, and include() it into your PHP script.
Save a copy of a library into your project, and include it into your PHP script.
--
At a basic level, code is either part of the interpreter (static or dynamic), or it is plain old PHP code that is include()ed into your project.
For your purposes, I can only suggest that you stick with an industry standard PHP distribution (pick a good linux OS, and use it's PHP). Then almost all the libraries you will need at the interpreter level are available as add-on packages, and the complexity of that is left up to those who do it every day.
On RedHat/Centos, you might run:
yum install php php-memcached php-gd php-pecl
--
Regarding all the other kinds of libraries that you might want to use, it's most likely best to adopt a good PHP framework which takes care of all that for you.
Some examples are:
Zend Framework
CakePHP
Codeigniter
http://www.phpframeworks.com/
Etc...
(not in any order, just ones that came to mind)
Provided that you have taken the standard approach of using RPM's or similar to manage the compiled in aspects of PHP and extensions, then a good solid framework will take care of the inclusion of all your additional PHP library code you need.
What the end result is, is that you focus on delivering a product, and not on all the infrastructure that you would otherwise have to learn and invent.
--
php.ini is parsed and run when PHP starts (each time for command line, once per server start in apache). It defines a lot of settings, includes a lot of modules, configures those modules, etc...
You can actually override some settings in php.ini with the ini_set() function in PHP. However, this is only effective for some settings. Others need to be set before your script starts.
When running under apache, you can add lines to .htaccess and <VirtualHost> directives which totally override PHP.ini for that directory/virtual host.
(please correct my syntax and remove this note if it is wrong)
<VirtualHost *>
ServerName www.example.com
DocumentRoot /home/joe/site/docroot
php_value include_path "/home/joe/site/php-code"
</VirtualHost>
--
In response to your #6 question about your own library and the best way to package it, I suggest you first evaluate the need of the library. And if you really are on to something, then find out the most common way people are doing it. If it is a simple library, then a .php file with a nice website would be sufficient.
--
Maybe a bit rambling, but I hope this points you in the right direction.
All directly related to PHP:
Usually just copy and make sure something, that wants to use it, knows where it is.
An extension is usually written in C and loaded by the interpreter, whereas a library usually means a native PHP library.
Dont know, what you want know here. The ini loads extensions and set up some settings. Its not directly associated with installations, .... You can set up your include-path (or something) here.
You can install libraries with it ;) Dont know either, what you want to know.
usually require(_once) or include(_once). For classes you can set up a autoloader. Refer to the PHP manual.
package/Archive (zip, gz, tarball, ..) it and make a download link? Also: Dont know, what you want.
If you want to write PHP libraries and want a simple way for packaging and distribution, than have a look at PEAR.
I am working on a project that requires reading text files, extracting data from them, and then generating reports (text files). Since there are a lot of string parsing, I decided to do it in Perl or Python or PHP (preference in that order). But I don't want to expose the source code to my client. Is there any good compiler for compiling perl/python/php scripts into linux executables?
I am not looking for a 100% perfect one, but I am looking for an at least 90% perfect one. By perfect, I mean the compiler doesn't require to write scripts with a limited subset of language features.
I'm sorry, it's simply not worth spending your time on. For any language you choose (from among the ones you listed), for any compiler/obfuscator someone chooses to come up with, I promise you I can get readable source code out of it (within an hour if it's Perl; longer if it's Python or PHP simply because I'm less acquainted with the implementations of those languages, not because it's intrinsically harder with those languages).
I think you should take a better look at what your goals are and why you want to work for a client that you're assuming a priori wants to rip you off. And if you still want to go ahead with such a scheme, write in C or Fortran -- certainly not anything starting with "P".
There does exist a Compiler for perl, called perlcc. I'm not familar with perl, but it looks like what you're looking for.
There are 3 options of encrypting Perl code:
Use PAR to create executable file with PAR::Filter::Obfuscate or PAR::Filter::Crypto
Use Filter::Crypto::CryptFile (will require some modules installed on target OS)
Turn into module and encrypt into Module::Crypt.
Also you can try B::C - it was removed from core Perl distribution and is now available on CPAN.
So far we've heard about perlcc and PAR with some obfuscation filters. These may work.
I have had very good luck with ActiveState's PerlApp which is part of their Perl Dev Kit.
It works well to bundle your code and hide it. You can try it for free, and it comes with some nice extras. Whether it is expensive or cheap depends on your perspective. For me, it was cheap. The cost in time of getting code hiding working and reliable with PAR or messing with perlcc was easily less than the price of the package. YMMV.
For Python You can call your code and give the *.pyc file to the client.
For linux an executable is something which has +x set, so there's no need to compile scripts. To hide your sourcecode you could use an obfuscator. This makes your sourcecode unreadable.
I've never used this, so I don't know how easy it is to setup, but you could use HipHop PHP to turn your PHP scripts into C++ code and compile them. (Assuming you choose to write them in PHP)
http://developers.facebook.com/blog/post/358
http://github.com/facebook/hiphop-php
For Python you can use cx.freeze. I have not used this but I believe that it basically bundles the .pyc into a zip file and adds an executable front-end.
Alternatively you could try compiling you Python code with Cython. this translates a modified version of the Python language into C code, which can then be compiled. This is normally used to write high performance extensions or interface with existing C libraries, but the latest version can also be used to make a complete executable.
I am developing a php application which my customers will download and install on their own servers. I know the base requirements for my application (like min. php version) but is there a way to generate a list of requirements that needed to run my application on windows or unix systems?
Thanks.
You mean, generate a list of requirements based on an analysis of your source code?
While in theory, that might be possible, I don't think such a solution exists. I think there is no way than analyzing your code by hand, with the PHP manual very close by.
Do you use GD? Then you need PHP with the GD module. Do you need to create GIF images with GD? Then you need GD, but not between versions 1.6 and (I think) 1.8. Do you use PDO? Then you need PHP > 5.1.0. And so on and so on.
In short, I'm afraid think this is going to be a manual process. Manual also as in "PHP manual" - the User Contributed Notes to each function and method are a gem, and any common cross-platform problems are usually noted there somewhere.
While you can trust that PHP x.y.z has a defined set of functions and behaviour, be sure to test well before you declare something suitable to run on a different server. IIS's support of PHP is way better now, I'm told, but the last time a ported a big PHP application over to IIS, it took me three days to work around all the mysterious bugs.
Just be aware of what you are using. For example, you should clearly communicate if you need something like .. a special database binding ( other then mysql ), xml libraries etc.., or even better, create an installer that is bundled with your software that checks that kind of stuff.
Other than that, there should be no problems concerning different servers ( apache / iis / fastcgi.. ). So to answer your question: you have to generate that list all by yourself.
As others have said, you'll need to manually keep track of special libraries and functions you're using. If you need PHP4 compatibility then you won't be able to use the built-in XML libraries for example. You can also check the list of functions added to PHP 5.
One thing I would recommend is installing WampServer if you have access to a Windows machine. Aside from being good for local development, you can download modules for most Apache/PHP/MySQL versions and test combinations.
When building some of my PHP apps, a lot of the functionality could be coded using PEAR/PECL modules, however, the fact that some people using it may not have the access to install things, It poses a puzzler for me.
Should I forsake some users to use PEAR/PECL for functionality, where these will allow me to have a system coded up quicker than if I wrote my own functionality, but eans that it will exclude certain people from using it.
It partly depends on how much time you have, and the purpose of the project. If you're just trying to make something that works, go with PEAR/PECL. If you're trying to learn to be a better programmer, and you have the time, then I'd recommend taking the effort to write your own versions. Once you understand the innards of whatever you're trying to replace, you may want to switch to the PEAR/PECL version so that you're not wasting time reimplementing what has already been implemented...
...but on the other hand, preexisting tools don't always do exactly what you need, and sometimes have overhead that doesn't do you any good. This is why Unix command-line tools are so small and narrow of purpose; nobody really needs a version of 'ls' that can do anything besides what 'ls' can currently do. Your version of whatever PEAR library will, by virtue of being written by you, do exactly what you need doing. It requires some careful thought...
...but on the gripping hand, don't spend too much time thinking about it. Spend five minutes, make a decision, and start coding. Even if you make the wrong decision, you'll at least have gotten more practice coding. :-)
Save on development time by developing with the pear libraries, and provide the libraries bundled in what you distribute (though you'll have to make sure it obeys licensing requirements)
I would not depend on certain PECL extensions being installed unless you're doing something particularly related to one (say an XDebug web-frontend or something), the majority of installs will be carrying a fairly vanilla set of extensions.
My suggestion is to start with assuming PEAR/PECL modules, and get the rest of the code done. Then, once you've got most of your code working the way you want, you can evaluate going back and piece by piece replacing the outside code with your own. Plus, by then you'll have a better idea of the impact using those has on your userbase.
Code it initially using PEAR/PECL and if you get people asking for a non PEAR/PECL version, start coding your own alternatives then for such a version.
The initial development will go much faster with this, and you may find that no-one cares about requiring 3rd party libraries once you have started releasing apps.
Use PEAR but allow for including the PEAR packages inside your project. All PEAR packages can be separately downloaded from http://pear.php.net/ and can be put anywhere. Depending on convenience and licensing issues you could then package all the required PEAR files with your project or tell users how to download and "install" them.
What I do most times is I'll never use PEAR installed globally on a server. Versions can change and affect your application.. Instead I have a config file (in my case XML) that lists all the packages required and their versions. The installer connects to my personal FTP repository and downloads and installs all the PEAR packages locally in $PROJECTBASE/lib/pear/ .. And PEAR is run locally instead of globally. Something you may want to consider.
Using PEAR is no problem, if users do not have root access to their webserver, they can simply download the PHP files from pear.php.net and add it to their include path. PECL's a little more tricky to work around, since there's often no way to install new modules without root access.
You need to watch out because a lot of modules in pear are really of pretty low quality.
Some are great, don't get me wrong, but don't assume that anything in pear, by virtue of being in pear, is at any given quality. Which means you need to at least skim the source of a pear module before deciding to use it, which for simple enough tasks may take more time than going without pear.
pecl is different, however. Extensions tend to be better vetted and tested, else they'd crash php.
Reiterating much of what's already been said: http://www.codinghorror.com/blog/archives/001145.html