php-general Digest 29 Mar 2012 16:23:39 -0000 Issue 7751
Topics (messages 317334 through 317337):
Re: Uploading and creating an email attachment, WITHOUT aDB on server
317334 by: tamouse mailing lists
Re: updating code asap to multiple domains, windows to unix, with source
control software (was: Re: [PHP] including PHP code from another server..)
317335 by: tamouse mailing lists
317336 by: tamouse mailing lists
DateTime wierdness
317337 by: MartÃn Marqués
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 Tue, Mar 27, 2012 at 8:33 AM, Maciek Sokolewicz
<maciek.sokolew...@gmail.com> wrote:
> Also note: checking file extensions has nothing to do with security; relying
> on such a crude technique to work is a very very bad idea. It also limits
> the possible formats that people would like to send their CV as; for example
> I can imagine people would want to use extensions such as .doc, .docx, but
> also .pdf. If you only allow those, you'll make life hard on people wanting
> to post a .txt or .rtf!
Especially those of us who keep our resumes in YAML.
--- End Message ---
--- Begin Message ---
On Tue, Mar 27, 2012 at 5:47 AM, rene7705 <rene7...@gmail.com> wrote:
> Yea, i'm quite sure I want to develop on Windows 7. Ubuntu still has
> quircks when it comes to using 3 monitors on a single system, as far as I
> know. I just like windows 7 a lot better at the moment.
> And how would it be dangerous to do so?
You can certainly develop on windows all you want. Before pushing
things to a production environment that's different from your
development environment, you should really run tests in (at least) a
staging environment that is as close to production as possible. This
can easily be done on your own system using a VM. It helps a lot to
write portable applications in PHP, which is deftly simple to do in
most cases. If you do have different things you want configured on
various platforms (development, testing, staging, production, forex)
you can do that in a number of ways (setting envars, testing the
hostname, keeping a separate configuration file outside of the source
control tree, etc)
--- End Message ---
--- Begin Message ---
On Tue, Mar 27, 2012 at 7:24 AM, Curtis Maurand <cur...@maurand.com> wrote:
>
>
> rene7705 wrote:
>> On Tue, Mar 27, 2012 at 1:21 PM, Peter Ford
> <p...@justcroft.com> wrote:
>>
>>> On 27/03/12
> 12:13, rene7705 wrote:
>>>
>>>> hey, I just read
> the rsync man page for the first time, and while it
>>>>
> sure
>>>> looks simple enough for my taste, wouldn't updating
> multiple remote
>>>> domains
>>>> be like a
> whole series of the same FTP updates to these different
>>>>
> domain
>>>> directories there? In other words, take a long
> time because of my
>>>> 200kb/s
>>>> link to the
> unix hoster?
>>>>
>>>>
>>> The first
> time might be slow, but you can then do incremental updates
>>>
> which would be a lot quicker.
>>>
>>> ok, that'll do
> nicely..
>
> Depending upon whether or not you have shell access to
> the hosts, you could update a host and then use rsync from that host to
> the rest.
If rsync will work to your remote hosts, then can I safely assume you
do have ssh access to them (rsync won't work without it unless you can
launch an rsync daemon on your remote hosts).
If so, then I don't think you really want to do the rsync thing at
all, really. Instead, I'd use git or mercurial (or even svn or cvs
will do). When you have your changes ready, push them to a remote
repository (github.com or gitorious.org, say). Then you can pull the
updates from the net by running the corresponding pull from the
repository on the remote hosts.
Let me also say that you should be keeping *everything* you develop in
source control. It goes beyond just being able to backtrack if
necessary, although that has been it's primary function. Keeping track
of your own development efforts, even solo, can be very important to
maintaining your code. Additionally, as you can see above, it aids
greatly in deploying your code. Additionally, if you keep your
repositories for any open source work on a public repository, it's
advertising for your work and a simple off-site backup plan. With
shell access, you can also create your own private repositories on one
of your host accounts.
Anyway, this has drifted far in to the topics of managing and
deploying code, not so much PHP.
--- End Message ---
--- Begin Message ---
Can someone explain to me this weierdness I see when using the
DateTime module of PHP.
Here I send 14/14/2012 which is not a valid date, and I would expect
to recieve false, but instead, it looks like it wrapping to the next
year, as if 14 monthas are 1 year and 2 months. That isn't what's
supposed to happen, or is it?
$ echo "<?php var_dump(DateTime::createFromFormat('j/n/Y',
'14/14/2012')); ?> "|php
object(DateTime)#1 (3) {
["date"]=>
string(19) "2013-02-14 13:20:22"
["timezone_type"]=>
int(3)
["timezone"]=>
string(20) "America/Buenos_Aires"
}
--
Martín Marqués
select 'martin.marques' || '@' || 'gmail.com'
DBA, Programador, Administrador
--- End Message ---
