The Pineco.de blog has a new tutorial posted that the Laravel users out there will find particularly useful. In their latest post, they introduce some basic Eloquent searching techniques that can be used to easily locate data via currently available Eloquent functionality.

When our app is smaller – for example at the beginning – it’s enough to apply small, handmade solutions. It’s true for database searching as well. It’s not necessary to pull in a package instantly. Most of the time we can use some simple techniques to perform searches in Eloquent.

[...] Searching is a vital part of any application. A good interface helps the user to retrieve the information it needs. So it’s essential to bring a good solution both on front-end and back-end. In this post, we are not covering any UI or front-end related topics. [...] So for now, let’s talk about MySQL and Eloquent only.

In the post, they share a few methods for searching data that don't require any additional service or package. They're mostly just taking advantage of features the MySQL database supports but they're showing how to use them in a Laravel environment:

• simple "where" clauses
• using the fuzzy matching of the "like" keyword
• searching JSON columns by a "path"
• using "sounds like" to find similar values

Each item on the list comes with a few lines of code showing how to use it via an Eloquent model and a brief explanation of what's happening behind the scenes in the database.

Matt Stauffer has continued his series looking at new features in Laravel 5.3 with a look at advanced operations on collections, specifically related to the "where" handling.

If you want to filter a Laravel collection to only those records which meet particular criteria, you're most likely going to reach for filter() or reject(). [...] You might not know it, but there's also a where() method that's pretty simple that gives you the same functionality.

He points out the main difference in Laravel 5.3 - the change from a strict check (the ===) to looser checking (==) and the ability to modify the operation to your liking. He also links to more information about this and other methods in the Laravel code on GitHub.

In PHPMaster.com's latest tutorial Lukas White introduces you to using the Yahoo "Placemaker" web service to geographically locate a place from a free-form text string. The results include "place details" like the type of the location, latitude, longitude and how confident they are in their match.

The challenge then is to do two things: work out what place you could be talking about, disambiguate if necessary, and then identify exactly where on Earth that is. That's what I'll show you how to do in this article; by using a freely available web service, we’ll write a simple program to ask users where they are (and ask them to clarify if necessary) before identifying their responses in concrete terms.

He shows how to make a request to the Placemaker web service, passing it a string coming from the user, to be located. The POST request contains a few pieces of data including an application ID , your desired output type and the language you're using for the input. His example code uses curl to make the request and handles it (the XML response at least) with a call to simplexml_load_string.

In this new post to his blog, Brandon Savage looks at a few methods you can use to help reduce the overhead connecting to the database can cause.

Below are a list of my top five quick-and-dirty strategies for improving database performance in web applications. These suggestions are culled from recent experience and mixed with some ideas that I've implemented in my own code. They're not high level, but they are something we need consistent reminders about.

Here's the short version of the list:

• Try caching
• Reduce the number of queries that run
• Use indexes
• Optimize data usage
• Avoid functions in WHERE statements

You'll have to check out his post for the full versions, though.

Robert Peake has a new post today with a brief look at where PHP has come from and some of his opinions on the future of PHP in 2006.

We saw the release of PHP 5.1, the renaming of the CSV trunk to 6.0 (in attempts to beat Perl to the punch, apparently), massive security concerns raised by applications ranging from phpBB to Mambo, Zend's numerous partnerships and announcement of the Zend framework, great improvements to Pear, more conferences, more enthusiasm, more realization from the enterprise that PHP is where web application development is headed.

So, where is PHP going from here?

He predicts that the increased push Zend is making for the framework will continue to help improve PHP's image, especially with some of the hurdles PHP has to overcome (including security issues and getting past other lingering problems from PHP's past).

Robert Peake has a new post today with a brief look at where PHP has come from and some of his opinions on the future of PHP in 2006.

We saw the release of PHP 5.1, the renaming of the CSV trunk to 6.0 (in attempts to beat Perl to the punch, apparently), massive security concerns raised by applications ranging from phpBB to Mambo, Zend's numerous partnerships and announcement of the Zend framework, great improvements to Pear, more conferences, more enthusiasm, more realization from the enterprise that PHP is where web application development is headed.

So, where is PHP going from here?

He predicts that the increased push Zend is making for the framework will continue to help improve PHP's image, especially with some of the hurdles PHP has to overcome (including security issues and getting past other lingering problems from PHP's past).