Chris Hartjes is asking for suggestions to help solve a common problem for developers (remote or otherwise) that have to develop in a non-local setup: a better method for remote code development.

I've been playing around with Sublime Text (because of the awesome vim bindings) and was thinking about why do I always have to be logged into the remote server to do my work. Normally I connect using SSH, then attach to my tmux session and then fire up vim. This is okay but it lacks a certain elegance in it's approach. [...] What I'm chafing against is having to deal with multiple environments all the time to get my work done.

His ultimate goal is to be able to update and commit code without having to be logged into the remote server - essentially to replicate the local development experience regardless of the underlying technology. Have a suggestion or a method that's currently working for you? Leave him a comment!

On the PHPClasses.org site they've posted the latest episode of their "Lately in PHP" podcast. This time the focus is on a recent article that was posted to the site about finding good developers by looking in the right place.

The recently published article on attracting talented Web developers by offering remote job positions raised an interesting debate on the challenges, advantages and disadvantages of this way of working. This debate was the main topic of discussion of the episode 18 of the Lately in PHP podcast with Manuel Lemos and Ernani Joppert, who were joined by César Rodas. César is a top PHPClasses contributor that has been working remotely for several years for companies around the world.

You can listen to this latest episode either via the in-page player, by direct download or by subscribing to their feed.

Lars Tesmer has a suggestion for all of the unit testers out there (you do unit test your code, right?) when needing to test a piece of code that makes a call to something on the file system or a remote resource. Their examples come from tests written against the Assetic codebase.

For our most recent After Work Hacking my co-workers and me decided to write unit tests for the open source project Assetic. That turned out to be a better decision than our last one, yet we still ran into an interesting challenge.

In testing the HttpAsset class from the tool, they came across the problem - a call to a remote/file resource that could not be tested because of a file_get_contents call that depends on an external source. They came up with a few options to try to test this example, some better than others:

• Give it a real URL to test with
• Wrap the file_get_contents inside of a new class (ex. a "ContentFetcher")
• Use vfsStream to mock out the file system in the unit test

In their case, vfsStream couldn't be used due to how the fetch call was made, but the tool can be very handy if you need to mock out an external file system resource.

On the Ldeveloper Tech Blog today there's a helpful new post about an error PHP's SOAP extension could throw about not being able to connect to the host despite all settings being correct.

I receive this nasty error yesterday and it took me some time to figure out the problem: "Fatal error: Uncaught SoapFault exception: [HTTP] Could not connect to host in...". This ["new SoapClient"] line passes without any problems and this [var_dump on __getFunctions] shows the function prototypes correctly.

His script connects to the service as its supposed to but the "could not connect" is still thrown. He found a few references to OpenSSL issues that could cause it, but his code was correct so he turned to the other side - the service itself. As it turns out, it wasn't configured correctly.

It was configured to send invalid url and the function calls were using that invalid url. So there are two solutions [...] the first is to configure the server correctly. The other is to give __doReguest the correct location.

On the PHP on Windows blog from DZone.com Krzysztof Kotowicz has a new post - part one in a series on securing your PHP application - a look at securely including remote code from a source outside of your application.

First post of the series discussing various methods of including remote PHP code in your application - from security standpoint. In this post we discuss the history of remote code execution vulnerabilities in PHP apps and ways to prevent them. We finish off by presenting an unsecure method of including a remote code and describe what is the problem with that method.

He looks at the insecurity of a standard include/require, the allow_url_include php.ini setting and the issues with using hardcoded locations (like incorrect DNS records pointing to the wrong host).

On IBM's developerWorks there's a recent article from Vikram Vaswani about using the oEmbed tool to pull content into your site from sources like YouTube, Twitter and Facebook.

If you have your photos in Flickr, your videos in YouTube, and your TV shows in Hulu, how do you bring them all into your blog posts on Blogger? Of course, you can do this by hyperlinking to the appropriate content, but wouldn't it be nicer if you could just embed them into your post at the appropriate place? Enter oEmbed.

He gives examples showing how to pull in content from a few different places - a video from YouTube, one from Revision3 and an image from deviantART. He also talks about using the oohEmbed service to access additional content on things like Wikipedia, Slideshare and Amazon. There's also a bit at the end looking at an alternative PHP library that could be used to do similar things, php-oembed.

As reported by both The Register and Zend, there's a new remote exploit bug that possibly has something to do with the way 32-bit processors handle floating point numbers.

From Zend:

Due to the way the PHP runtime handles internal conversion of floating point numbers, it is possible for a remote attacker to bring down a web application simply by adding a specific parameter to a query string in their web browser.

The bug, found here on bugs.php.net, has been reproduced on Windows and 32-bit linux systems and can cause the server hang and/or crash as a result. The real issue comes from this bug on the x87 FPU design. The bug has already been fixed in the latest SVN versions (including 5.2 that was end-of-life recently). A release to fix the issue should be coming shortly.

As a part of this year's TEK-X webcast series, Cal Evans will be presenting today on a subject near and dear to his heart - working with (and correctly handling) remote developers for your projects. From the php|architect blog:

Come join us for this week's TEK·X webcast as Cal Evans discusses the details of managing remote developers. Cal won't be speaking on why you should allow your developers to telecommute - he has done that already. For those who see the light, however, he will give practical advice on the tools and techniques to use when managing distributed teams.

The webcast will be happening today at 1pm (EDT) and there's still spots open, so if you want to get in on this great session, head over to the gotomeeting page and signup!

In this new post to the Ask About PHP blog they take a look at one of the basics of using PHP - fetching the data from a remote URL via the cURL extension.

In PHP, there are actually four ways to access a remote URL - fopen() fsockopen(), cURL extensions and HTTP_Request class from the PEAR library. Now, choosing one way over another really depends on your needs for simplicity, control, and portability. Generally, I prefer using cURL simply because it's easy to understand and it's really powerful.

You'll need to have cURL enabled to be able to follow along. The examples show how to fetch a single remote page, a protected remote page, sending a POST request and fetching the URL with custom headers.

On the PHPClasses.org blog Manuel Lemos has a recent post looking at a method for sending emails using a remote SMTP server (like Google or Yahoo's) via this package.

In most hosting environments, the PHP mail() function is sufficient to send e-mail messages without problems. However, there are situations on which using the mail function is inconvenient and may prevent that your messages reach the destination. [...] Therefore, you may need to find an alternative way for sending your e-mail messages from PHP.

The package lets you define a username/password, server, whether to use a SSL connection or not, and if the connection needs to use the TLS protocol.