Matt Stauffer has a post to his site for the Laravel users out there wanting to seed "transactional emails" from their applications. In this tutorial he shows you how to use the SparkPost service to send emails with very little effort.

Recently, Mandrill announced that they'd be sunsetting their transactional email service and instead rolling it in to a secondary service for paid MailChimp users. That's fine for them, but many of us were using it for small one-off apps and weren't interested in all of a sudden paying money to send 100 emails a month.

[...] But right when Mandrill announced their pricing change, a new transactional email provider came out of nowhere: SparkPost. [...] So let's walk through the process of signing up and moving Giscus, my app for notifying you of comments on your gists, from Mandrill to SparkPost.

First he walks you through the process of getting a SparkPost account set up and configured to receive messages from your application. He then moves over to the Laravel side, upgrades his installed version and configures it with the "secret" value SparkPost provides and changes the MAIL_DRIVER value - that's basically it.. He also includes some screenshots of other parts of the SparkPost admin interface to show some of the other functionality included.

The SitePoint PHP blog has posted a tutorial continuing on from some previous advice with even more defensive programming practices you can use in your PHP applications.

Many people argue against defensive programming, but this is often because of the types of methods they have seen espoused by some as defensive programming. Defensive programming should not be viewed as a way to avoid test driven development or as a way to simply compensate for failures and move on. [...] What are these methods, if not ways to anticipate that your program may fail, and either prevent those, or else ways in which to handle those failures appropriately?

They go on to talk about the ideas of "failing fast" when errors happen in your application with an extra suggestion added on - "fail loud" too. The tutorial then looks at four different places where more defensive programming techniques can be applied (and how):

• Input validation
• Preventing Accidental Assignment in Comparisons
• Dealing with Try/Catch and Exceptions
• Transactions

They end with a recommendation that, while you should fail fast and loud when issues come up, be sure it's not to the determent of the overall user experience or sharing messages with users that may just confuse them.

You may have been using relational databases in your PHP applications for a long time (PHP loves MySQL after all) but you might not have ever dug deep enough to understand how those databases work internally. In this detailed tutorial from Coding Geek they dive way in and cover everything from the basics out to complex sorting, management components and query handling.

When it comes to relational databases, I can’t help thinking that something is missing. They’re used everywhere. [...] you can google by yourself “how does a relational database work” to see how few results there are. [...] Are relational databases too old and too boring to be explained outside of university courses, research papers and books?

As a developer, I HATE using something I don’t understand. And, if databases have been used for 40 years, there must be a reason. [...] Over the years, I’ve spent hundreds of hours to really understand these weird black boxes I use every day. Relational Databases are very interesting because they’re based on useful and reusable concepts. If understanding a database interests you but you’ve never had the time or the will to dig into this wide subject, you should like this article.

He covers a wide range of topics during the post:

• O(1)) vs O(n2) (or how data sets are handled based on size)
• Array, Tree and Hash table
• Global overview (structure of the database system and its pieces)
• Query manager
• Statistics (and optimizing storage of the data)
• Data manager
• Deadlock
• Logging

Each of these topics comes with a lot of explanation, examples of how the internals are functioning as well as diagrams to help make a bit more sense. If you've ever really wanted to know how that database you use functions, this is definitely the article to check out.

Mathias Noback has posted another in his series looking at the concepts and implementation of command bus handling in PHP. In this new post he looks at some of the responsibilities of the bus and provides a few examples to help drive the point home.

In the previous post we looked at commands and how you can use them to separate technical aspects of the input, from the actual behavior of your application. Commands are simple objects, handed over to the command bus, which performs the change that is needed. [...] So the command bus contains some kind of a lookup mechanism to match commands with their handlers. Some command bus libraries use a naming convention here (e.g. handler name = command name + "Handler"), some use a kind of service locator, etc.

He starts off talking about the main point of the article, giving an overview of what he sees are the basic responsibilities of the command bus. He also sheds some light on methods he's seen for keeping it from becoming a "big inarticulate unmaintainable class". He then gets into his two examples: database transaction handling and protecting the original order of commands. He shows how his SimpleBus package handles most of this for you and shows how it follows the "chain of responsibility" design pattern to make it work.

PHPBuilder.com has posted a new tutorial about creating automated FTP scripts to pull down information from a remote server (using FTP streams).

In 2007 I began working on a website project for an investment company in my hometown of Cleveland, Ohio USA. The purpose of this website was to automatically download financial data of traded securities from two (2) remote Web servers. [...] Both of these PHP scripts were set up on the Web server's "crontab manager" to automatically run at a set time each business day.

Code is included showing how to connect to the remote service (via curl) with a "ftp" stream-based URL as the location. Also included is an example using a fopen call to the URL and inserting the resulting data into their tracking tables. The other script pulls the data out and adds a new record to a transactions table for the current day.

In this new post to the GotoTech.com blog Eric Burns talks about a way he's "tamed Doctrine's 2000 flushes" with a wrapper around the EntityManager to make controlling the database flushes simpler.

For my project I decided to use the Doctrine 2 ORM to manage my data layer. We also use this at work, so the biggest reason I chose this was to be able to learn more about Doctrine to help me in my job. But this decision also makes sense for my project because my entity relationships will likely be fairly straightforward for the most part and using an ORM will allow me to make a lot of progress very quickly without (I hope) causing me lots of trouble later on.

His handy wrapper (Data Manager) makes it simpler to perform the flush and still take transactions into consideration. His simple class includes "flush", "commit" and "startTransaction" methods that don't actually perform the flush until the commit is called.

On the php|architect site there's a recent tutorial from Cal Evans about building a transactional email system with the help of a simple library and the SES system from Amazon.

I love APIs. A well-defined API can make short work of a complex problem. It’s even more fun when you find a cool API with a great wrapper to make it simple to use. That’s what I found when I started playing with Amazon’s Simple Email Service; a tool that was easy to work with, solved a problem I needed solved, and had a simple to use PHP wrapper.

Based on the SES library by Dan Meyers, he includes the code to pull in a simple email template and populate it with the values you want, log in to the Amazon SES service and send the email via the remote service.

On the SitePoint blog there's a new article from Craig Buckler stating that MySQL transactions can't be emulated in PHP and shouldn't be discounted despite many developers seeing them as not much more than a performance hit.

My recent article, "Top 10 MySQL Mistakes Made by PHP Developers" was far more controversial than I expected. Several of the more intriguing responses were from PHP coders who considered transactions to be an unnecessary overhead. With good-quality PHP code, they argued, you don’t need transactions or MySQL's InnoDB storage engine. It's certainly true you don’t always need transactions.

He gives an example of a situation where database-based transactions would be very useful (inserting customer information) and points out that, despite the best intentions of developers, reducing as many layers and connections between SQL and code is a good thing. Transactions help you conform to the ACID ideas and keep data integrity by only having things in the database that were successful. He includes a small bit on using transactions as well.

On his blog today Brian Swan has posted the results of some of his research on transaction isolation levels in SQL Server PHP applications.

Last week I had the good fortune of presenting at the the Seattle PHP Meet Up on a topic I knew only a little about: transaction isolation levels. It was fun doing the homework to learn more and I'll share what I learned in this post. This post is only somewhat PHP-specific. I'll focus largely on the concepts behind database transactions and isolation levels. Most of the concepts I'll look at are database agnostic (although I will use SQL Server as the vehicle for explaining the concepts) and are supported by most relational database management systems out there (e.g. SQL Server, MySQL, Oracle, DB2, etc.).

He introduces database transactions for those not familiar (a key to understanding the rest of the post) and some PHP code that connects to a SQL Server and begins a transaction to update some banking information. He uses this example to show how to set up isolation levels like "READ UNCOMMITTED", "READ COMMITTED" and "SERIALIZABLE".

In a new post to her blog Zoe Slattery points out a big step in PHP's presence in systems all around the world - the inclusion of it into the CISC systems.

You probably don't realise it but it's very likely that sometime during the last week you will have have used IBM's CICS technology. [...] Last week PHP made it into CICS, PHP is now being used to build agile front ends and RESTful interfaces for the technology that underpins most of the world's large scale commercial systems. You don't get much more into The Enterprise than that!

IBM made the announcement back on Friday the 12th about the upgrade to the sMash WebSphere software. The update, a SupportPac lets developers run PHP inside of a CICS transaction and can be used to create REST services other applications/interfaces can use to directly communicate with the CICS system.