On the TutsPlus.com site they've posted a tutorial (by author Monty Shokeen) covering the use of PHP's built-in functionality to format date and time values such as the current date.

You'll often want to work with dates and times when developing websites. For example, you might need to show the last modified date on a post or mention how long ago a reader wrote some comment. You might also have to show a countdown of the days until a special event.

Luckily, PHP comes with some built-in date and time functions which will help us do all that and much more quite easily.

The tutorial starts with the basics of datetime handling in PHP, making use of the date function to get formatted output of either the current time or the timestamp provided. Several code examples are provided showing the output for month/day/year and hour/minute/second combinations. Next they look at how to get the current Unix timestamp, using that to calculate day differences and working with relative time strings.

The tutorial ends with a look at the DateTime functionality also included in PHP and provides several examples of it in use for both formatted date output and calculating time differences.

In a new post to his site Jason McCreary makes a case for writing clean code in your development processes. He makes three main suggestions of practices you can integrate into your workflow to help make the code you write cleaner.

I noticed [legacy codebases] all suffer from the same fundamental issue - inconsistency. Often the result of years of code patching, large teams, changing hands, or all of the above.

This creates a problem because we read code far more than we write code. So as I read a new codebase these inconsistencies distract me from the true code. My focus shifts to the mundane of indentation and variable tracking instead of the important business logic.

In my experience, I find I boy scout a new codebase in the same way. Three simple practices to improve the readability of the code.

His three suggestions for improving the overall code quality center around standardized formatting rules, consistent naming practices and avoiding nested code. He uses an example piece of code to help illustrate these recommendations with explanations for each.

As is mentioned in this post on the Laravel News site one of the improvements coming in Laravel v5.4 will be the ability to use Markdown formatting in your emails.

Laravel 5.3 introduced two new features around email, the Mailables and Notifications which allow you to send the same message through email, SMS, and other channels.

Building on top of these improvements, Laravel 5.4 is going to include a brand new Markdown system for creating email templates.

Under the hood, this feature implements the Parsedown parser with its companion, Markdown Extra so you can use tables.

They go on to describe how this feature is integrated with the "components and slots" handling also recently introduced in the framework for things like headers, messages, layouts and tables. Also included is some example code showing how to return the Markdown parsed version of a view, using them in notifications and how to use inline styling.

In a post to his site Matthieu Napoli shares some of his thoughts about "code style rationality" including code formatting in general and some suggestions on one of the harder things in development - naming things.

Habits are sometimes making us blind. We think X looks prettier than Y but that’s just the habit speaking. In this article I’ll try to take a rational approach at coding style. That means leaving the “it looks ugly/better” at the door.

If at any point you feel like something “just doesn’t look good”, breath in, breath out, and try it! Nothing beats hands-on experience, not even some random article on the internet.

He looks at a few subjects specifically (there's way too many to cover them all in detail):

• the use of trailing commas
• alignment of values in docblock comments
• keeping docblock comments minimal
• using the "Interface" suffix
• using the "Exception" suffix

He ends the post by reminding readers that the point is to think about code style logically and that no rules are written in stone.

On NetTuts.com today there's a post that talks about applying the PSR formatting to your application's code. If you haven't already read their introduction to the PSRs, it's highly suggested.

In a previous lesson here on Nettuts+, you learn about PSR; however, that article didn’t detail the process of integrating that coding style into your projects. Let’s fix that!

They briefly recap the main two PSRs (PSR-1 and PSR-2, but no mention of PSR-3 the logging interface) and show code examples of them being applied. They also point to the PHP_CodeSniffer tool that you can use to keep your code in the correct structure. Instructions are included to install it specifically for the Sublime Text 2 editor via package control. It's just a command-line tool, though, so it could be integrated with just about any other editor/IDE out there too.

In this new post to his site Gonzalo Ayuso introduces you to one of the more powerful parts of the PHP language - the DateTime object.

I’ve seen a lot of newbies (and not newbies) having problems handling dates in PHP (and even with SQL and another languages). When I see someone having problems with dates, I always ask the same question. I type in a text editor “27/11/2012″ and I ask him: What is it? If your answer is “This is a date” you should continue reading the post.

He talks about how the DateTime functionality replaces (much more effectively) some of the older date handling methods in PHP. He includes a few examples comparing it to date and showing how it can be used to compare dates. He includes a "Dummy" class he mocked up to show how you could work with DateTime to get/set formatted dates, set the format to use and get the current format. As always, he also provides tests for the code as well.

This is just the tip of the iceberg as to what DateTime can do, so I'd suggest checking out the manual page for it to see the full list of features.

In this new post Antonin Januska shares some reminders about what good code comments should look like - what needs to go in and what needs to stay out (you comment all your code, right?)

Code organization is a huge thing, especially for developers (because they deal with code), and often times it’s a philosophical debate as to how code should be documented, if spaces should be used instead of tabs, what kind of documentation should be used and so on. Yet, what no one brings up is the dire issue of COMMENTING. We can all agree that comments are essential (and sometimes used to build half-ass documentation on big systems) but what no one really mentions is the fact that people are crappy commenters.

There's two topics he touches on that (surprisingly) it's easy for developers to forget when writing their code - "be informative" and "use consistent formatting". A lot of the issues could be helped if developers made more use of DocBlock formatting which many IDEs already have support for.

On DesignLuv.com today they've posted what they call a style guide for PHP developers - some types on writing well-styled, easy to read code.

If you’re a new developer and are trying to hone in on your coding style, maybe try giving the following a go. These are simply some conventional formatting methods that are generally appreciated and supported by PHP developers and will improve the overall readability of your code.

They talk about a few different subjects - variable names, class and method naming, bracket spacing, default arguments, constants, loops and a lot more. It's good to see them including things like commenting and file name suggestions.

Brandon Savage has a reminder to all of the developers out there about working with input from your users - the burden is on you to format the data correctly, not them.

The simple answer is that whomever designed the form decided to place the validation of the data, and its massaging into the proper format, onto the end user. But there’s a more complicated issue at hand here: the fact that the developer either felt it wasn’t his responsibility to do the data formatting, or didn’t realize that not everyone would think to [input the data] way he does.

He suggests that it's more out of laziness on the part of the developer to want the user to give them the data in the format they want when, really, the application should take reasonably correct (it has to match the type they're looking for, after all) and massage it to what they need. If it doesn't cooperate after this, only then should they toss an error. His examples touch on phone number and date formatting.

Dave Marshall has posted part three of his series looking at how to land that perfect PHP job. In this part he focuses on the resume/curriculum vitae - often times your first impression to a potential employer.

In part two of this series, I discussed the technical know how I think will help get you your next PHP job. This part will discuss writing your Curriculum Vitae(CV, resume, etc.). There are a lot of contrasting opinions on this subject, I’ll make a few points, give you some further reading and you can adapt the opinions in to a top notch CV of your own. I’m no major expert and most of the recruitment I have been involved in has been for trainee developers, but these positions attract a high number of CVs, so I’ve seen a fair few.

He includes a few helpful hints like "Your CV does not get you a job", "Don't stuff your CV with keywords/acronyms" and some tips on formatting and proofreading.