On the SitePoint PHP blog there's a new tutorial posted from editor Bruno Skvorc looking at PHPBot, a chatbot tool that might help you look up PHP documentation questions a bit more easily (and quickly).

I came across PHPBot the other day (not to be confused with Botman or Fondbot) – a “chatbot” which helps you look up PHP manual entries and generates example code for them.

If you follow me on Twitter, you know I don’t believe in chatbots being chatbots – as someone who’s built some for both commercial purposes and personal ones, and as someone who was around in the age of IRC auto-responding scripts, I see chatbots as a little more than a marketing fad designed to impress today’s Snapchat generation. However, every now and then one will appear that’s actually useful. Could this be the one? Let’s take a look.

He starts off with some of the basic concepts behind the bot and examples of some of the output from documentation requests. He goes on to talk about the actual usefulness of the bot and provides some instances where it is still lacking in functionality. He also looks at several other subjects including Knowledgebase and Bugs, Autocompletion / Suggestion and Copy / Paste Friendliness.

If you've been to any PHP conference (or attended a PHP-related online event) in recent years, you probably have heard of the speaker/event feedback site Joind.in. The concept is simple: when you attend a talk or event you go to the site, give the speaker a star rating and leave them comments. This gives the speakers direct feedback on how they did and where they can improve. There's a a trick to giving valuable feedback, though, and Joshua Thijssen has posted some helpful tips to guide you and your comments in the right direction.

The joind.in website can be considered a presenter’s portfolio: it contains a list of talks they have done in the past (and where), plus it contains reviews from attendees. [...] This is why many conferences and presenters will talk about joind.in and ask you to rate and comments on their talks: it gives them feedback on how you experienced the talk, what can be improved to make it even better, and gives the presenters more chance to get accepted on even the larger conferences, where sometimes there are only 50 slots, but over 500 people submitted talks).

[...] Even though commenting and rating talks by itself isn’t really difficult and is quick to do so, there are some common “mistakes” and pitfalls which I’d like to discuss.

He breaks it down into five main points, elaborating on each as he goes through them:

1. Stars don’t tell you everything
2. Rate the presentation and speaker, not your expectations.
3. Don’t punish the presenter for external faults
4. Comment anonymously
5. Give suggestions on how to improve

For each one he also gives examples of good feedback versus comments that aren't as helpful to the speaker. Each one of these is an easy trap to slip in to, so remember them next time you're giving a speaker feedback (even if it's not on Joind.in!).

While the advice that Matt Stauffer gives in this new post to his site is more targeted towards people applying at his company, it's full of great tips for just about any job seeker looking to land a role in web development.

I just finished reading over 200 applications for our latest job posting, a Web Developer job at Tighten Co.. We still hire infrequently enough and are small enough that the two founders (Dan and me) and our operations manager (Dave) read every single application, which is hours upon hours for work before we even get to our initial phone screen.

Some applicants, and some tendencies among applicants, have stood out as best practices, but many more things have stood out as consistent turnoffs. So, I figured I'd share some with you here.

He includes helpful hints on topics like:

• actually reading the job description
• writing custom cover letters
• updating your site and resume to the latest information
• provide up to date code samples
• check spelling and grammar

He offers one other piece of advice that I think a lot of job seekers don't bother with: set yourself apart somehow. This may mean extra work on the application but it can yield very positive results. He ends the post with some extra tips he received as feedback on Twitter, asking hiring managers what they really want to hear from applicants.

The ServerGrove blog has posted a new tutorial with a selection of useful command line tools to help you in working with your PHP applications. None of them are PHP specific but are Unix-based commands that can help in every day development.

Linux provides a lot of interesting command-line tools that we can use when working with PHP projects. In this post we give you some useful commands.

They include examples of commands that can help with:

• Find all PHP files in the current directory
• Check the syntax of all PHP files in the current directory
• Get the size of each Composer dependency
• Find suspicious PHP files
• Find files with abstract classes
• List PHP settings for the xdebug extension
• Find empty files and/or directories
• List files currently open by a PHP process

As mentioned, most of the tools themselves are not PHP specific but these example commands do relate to things that are more in a PHP context.

The SitePoint PHP blog has posted the latest article in their Jenkins + PHP tutorial series (part four) with a look at some other useful plugins for use in your projects.

In the previous articles in this series, we set up Jenkins and our project and did an analysis of the first few builds. So far, we have seen interesting results come back regarding the quality of our project. In this article, we are going to take a look at some more tools and plugins which we can use for inspecting the front end assets.

The list includes tools for evaluating a wide range of technologies involved in web development like:

• CSSLint
• JSHint
• Open tasks (aka @todo)

Each tool has an example of what the output looks like and how to integrate it into the Phing build and in the Jenkins setup.

The SitePoint PHP blog has a new post by Jacek Barecki talking about documenting your code and some suggestions for keeping this documentation useful.

Pretty much every PHP developer writes comments along with the actual code. But the language itself doesn’t impose any rules on how to do so. You just have to wrap them around some specific tags and then you can write any content you want. So what exactly should be put in the comment blocks to keep them useful? Which parts of the code should be documented and which shouldn’t? In this article I will present some important rules which may help you in keeping your PHP code well documented and understandable.

There's three suggestions included in the article, each with a bit of explanation and a few screenshots to illustrate:

• Write code that explains itself
• Keep the balance
• Remember about the doc blocks

Volker Dusch has a new tongue-in-cheek post to his site talking about a few pieces of useful software that are not written in PHP...and why not?

Dear PHP Community, we need to have a talk about the insufferable state of your software stacks. It was recently brought to my attention that there is software out there, software we use every day!, that is NOT written in PHP. This is completely unacceptable! We are PHPeople! We’re not “Web” Developers, we are the web. And we sure as hell are not some fancy “Software Developer”, you can ask anyone on the internet! Seriously: If it’s not PHP how will we ever be able to extend and adapt it to our needs! We are slaves of our tools!

He mentions several tools that, yes, while not written in PHP are very useful to just about any developer out there (including git, Puppet and Apache). But, more seriously:

PHP is a language that enables absolute beginners to start creating on the web using FTP and notepad! It let’s us realize and validate our ideas blazingly fast and allows us to adapt our successful ideas to beautifully scale with our requirements providing and relying on solid, battle-proof tools.

In this recent post to his blog Anthony Ferrara looks at commenting in your application's code and how to be effective (and not so effective) when using them.

A few weeks ago I was sparked into a twitter conversation with Larry Garfield (@Crell) about the value of comments in code. [...] A pretty innocuous comment [about code that doesn't have comments] that is quite insightful. [...] That led to an interesting discussion that just couldn't fit on twitter. So let me explain...

He defines what he means by "comments" (DocBlock, general comments and legal information) and what sort of things should be inside of them. He also points out a few things not to do in you comments including being overly descriptive and restating what the code is doing (they should be less about that and more about the "Why"). Of course, there's exceptions and he touches on those briefly to finish out the post.

Phil Sturgeon, a developer on the Fuel framework project, has a new post to his blog asking a common question of all developers that set out to make the "Next Big Framework" - why write a new framework?

So we all know that the internet is full of frameworks. They've been the popular thing for the last 5 or 6 years and it seems to have become the "barrier for entry" or the "passage of rights" that 8 or 9 years ago used to be "hey I just wrote a phpBB clone!". There are plenty around but in this day in age, why would anyone write a new one? As somebody involved in a new PHP framework - Fuel - that has shaken a few opinions up I thought it would be interesting to share my thoughts and views on the situation.

While he agrees that there are plenty of other frameworks out there, maybe too many to choose from, he thinks that there's value in making something that's useful to you and the toolsets you're already used to. One of their goals with Fuel is to "make PHP as fun to use" as possible and things like built-in migrations and scaffolding (along with a command-line tool, Oil) help towards that goal.

A framework is essentially a way to put all of your best practises into a single place so that you can reuse them over and over again. This should make you more efficient and make your time more financially viable to clients. If the framework you use slows you down or does not cater for the way you like to develop then sack it off and do your own thing.

The CatsWhoCode.com blog has a new post today with what they call super useful PHP snippets that could help you out in a pinch.

Having the right code snippet at the right time can definitely be a life saver for web developers. Today, I’ve compiled 10 really awesome PHP code snippets that will, I hope, be very helpful in your forthcomming developments.

Their list of ten includes bits of code for:

• Super simple page caching (file-based)
• Convert seconds to time (years, months, days, hours...)
• Get current weather using Google API
• Get latitude and longitude from an address
• Save url to PDF