On the SitePoint PHP blog there's a post from Claudio Ribeiro introducing you to a new static analysis tool to help improve the quality of your code - PHP Static Analyzer, or "PHPSA" for short.

One requirement that never changes whether you are working on your projects alone or in a team, on small projects or big, is Code Quality. The bigger the project and the team, the harder it gets to maintain it.

A good way of slowing this increase in difficulty down is to use static analysis tools. Static analysis is the process of analyzing software without actually executing the program – a sort of automatic code review. Static analysis tools will detect common errors, enforce coding standards, and even clean up code blocks. The days of php -l filename are not over, but we now have a number of great tools that go the extra mile in helping us create and maintain high quality code.

They start with an example of using the tried and true "php -l" to lint an example PHP file but note that the yes/no answer it provides doesn't help give much feedback on the quality of the code, just its syntax. Enter PHPSA, a Composer-installable tool that does much more than lint checking. It also provides information about things like missing docblocks, function alias use and undefined property usage. they show an example of it in use on the command line, the results it provides and the changes made to the example class to fix the issues it found.

The Scotch.io blog has posted a tutorial combining Laravel and the Typeahead.js library to create a "smart search" in your application. Most of the tutorial centers around the Typeahead.js code though, so with a bit of tweaking it could sit on top of just about any framework out there.

In a big web application, like an online market or a social network, one of the most important parts of the app is the search functionality. Having a great search feature will help your users find the right content(users, products, articles) quickly and easily.

In this tutorial, we are going to learn, how to enhance your default search field in your site with real-time suggestions from the database. We will be using Laravel, jQuery and Typeahead (Bloodhound as the suggestion engine) to implement the smart search and Bootstrap for the styling. So, let's get started.

He starts off by introducing the Typeahead.js library and the Bloodhound suggestion engine. He shows the installation (either via Bower, standalone download or included from a CDN) and a simple template with a search form and other Javascript requirements included. The tutorial covers some of the options you can set, what kinds of datasets it can work with and templates to use for the results. Next up, he brings in a default Laravel project and a "search" endpoint that queries user data and returns a JSON dataset of the results. The two pieces are then finally tied together with a few updates to the Javascript already created.

In this post on Medium.com Gediminas Rapolavicius provides a word of warning to those creating APIs (interfaces for tools, not like REST APIs) - "don't try to be too smart", favor consistency over cleverness.

When designing an API, it’s tempting to do a bit of extra work and surprise the developers using it. It might be returning some additional information that would require an additional call otherwise, or try to predict the intentions and handle some specific cases differently. The intentions are perfectly fine?—?provide a pleasant, simple interface.

The problem is that it requires making assumptions which, sometimes, are inevitably wrong. The worst case is when the API makes an assumption of what the developer expect to get back, gets it wrong, and returns something unexpected. More work with docs, more bug fixing.

He gives two examples of things he's encountered where the idea of the API was simple but assumptions made turned out to make things a bit more difficult: PHP's own array_rand function and WordPress' update_post_meta. He briefly covers each and explains that, while the intentions seemed good, the implementation was a bit confusing (and at times inconsistent), causing troubles when not functioning as expected.

On the CodeGeekz site there's a new post showing you how to use the Imagick extension and a custom library to crop images based on their entropy (keeping the "busiest" part of the image).

The need to resize and crop images in order to create thumbs, is a very common scenario for most websites. For example a blog like this one uses images in the content of the posts, images which at some point are used to create a thumb for the homepage. In most cases, the thumb’s dimensions are not dynamic but are static throughout the website in order to better fit the template. This however creates a major problem when we try to automatically resize and crop our images in the desired dimensions.

He starts with an example of the normal kind of cropping based on a given height and width. He points out an issue with "smart cropping" and resizing the image with the cropping is done. Instead, he's made use of Imagick in his library to produce a better cropped image based on the parts of the image with the most entropy.

In this recent post from Jani Hartikainen he looks at the three different categories he sees developers fitting into - "smart-and-get-things-done", smart and "just a" programmer.

The other day I was thinking of programmer types. In a way, I think there are three kinds of programmers when looking at a high level [...] So how do you determine if a programmer goes into one of these categories?

The "just a programmer" is the developer that writes code because it's a better job with little passion. The "smart programmer" are talented developers but they miss the big picture things. The "smart and get things done programmer" can be the most ideal of the three - they're the ones with the vision and passion to really make great applications.

Ben Scholzen has written up a post about how regular PHP arrays can be used as a native configuration option for your applications.

I was asked many times how I organize my config files, and my response was always the same, until some time ago when I switched began refactoring the codebase of my blog. [...] Looking at [the advantages of PHP config files], you may ask now why not everbody is using them. Well the problem mostly is that you cannot create extend-sections (when working with Zend_Config for example).

He compares an example of a method that, using a base config file with some "smarts", you can have it automatically pull in certain files and overwrite settings from the array inside. A sample "other config" file is also included, showing the definition of some PHP settings, resources and database information.

Brian Moon has posted some thoughts about "the post" that Terry Chay recently wrote including comments on smart versus intelligent, object nonense, and funky function names.

So, if you are not smart, then stop coding PHP. Its a good thing that C developers are smart. They have to remember all those functions. Assembly language developers don’t have to remember functions. I guess they are not smart?

Ok, that last paragraph was tongue in cheek. Knowing 3000+ functions does not make you smart. It means you have a good memory. I will take intelligence over smart or a good memory any day.

His comments on the "object nonsense" makes note of the difference between functions and methods and the function naming issue - well, he has "no solid defense" as they do make it difficult to learn the language and send some developers running back to the manual to make sure the parameter order is right each time.

Brian Moon has posted some thoughts about "the post" that Terry Chay recently wrote including comments on smart versus intelligent, object nonense, and funky function names.

So, if you are not smart, then stop coding PHP. Its a good thing that C developers are smart. They have to remember all those functions. Assembly language developers don’t have to remember functions. I guess they are not smart?

Ok, that last paragraph was tongue in cheek. Knowing 3000+ functions does not make you smart. It means you have a good memory. I will take intelligence over smart or a good memory any day.

His comments on the "object nonsense" makes note of the difference between functions and methods and the function naming issue - well, he has "no solid defense" as they do make it difficult to learn the language and send some developers running back to the manual to make sure the parameter order is right each time.