This week's Programming With Anthony video is up! In it, we discuss the foundations of Boolean Logic and introduce some very interesting tools for analyzing logical constructs (including Truth Tables and De Morgan's Laws).

You can view this latest video over on YouTube or get caught up on the entire series with the full playlist of this and past episodes.

This bring us back to the question whether it's feasible to eliminate duplicated strategy logic via Inheritance rather than switching over to plain Composition. Indeed it is, and the clean up process can be conducted through an ubiquitous pattern known as Template Method. [...] Simply put, there's a base class (usually an abstract one), which declares a concrete method (a.k.a. the template) responsible for outlining the steps or hooks of a certain algorithm. Most of the time the base type provides boilerplate implementation for some of those steps and the remaining ones are delegated to subclasses.

The subtypes then override the base's functionality and extend it with their own. They show an example of this by making a jQuery image slider (using this plugin) , an "AbstractCycleSlider" class and two subclasses for two other types - "FadeSlider" and "ScrollSlider", each outputting their own HTML. It also shows how to implement a slider using a different plugin and output both in the same script.

One of the most confusing design pattern is persistence. The need for an application to persist its internal state and data is so tremendous that there are likely tens - if not hundreds - of different technologies to address this single problem. Unfortunately, no technology is a magic bullet. [...] In this tutorial, I will teach you some best practices to help you determine which approach to take, when working on future applications. I will briefly discuss some high level design concerns and principles, followed by a more detailed view on the Active Record design pattern, combined with a few words about the Table Data Gateway design pattern.

Included in the post is a high-level application design with the business logic is at the core and the persistence technology/layer exists outside of it. They show how to create a simple, working solution for a persistence layer to handle a blog post and its contents. It talks about characterization tests, the table gateway design pattern and the possible move to the active record pattern.

Inheritance offers a straightforward way to easily spawn a large number of objects that are semantically related to each other without having duplicate code. The concept is ridiculously simple - yet powerful: you first drop as much logic as possible within the boundaries of a base type (usually an abstract class, but it could be a concrete one), and then start deriving refined subtypes according to more specific requirements. [...] Not surprisingly, this repetitive encapsulation/derivation cycle lays down on the formalities of a design pattern known as Layer Supertype.

They describe the "supertype" as a replacement for an overly bloated domain-related model. Their example replaces a PostInterface/CommentInterface with a more generic "AbstractEntity" that handles some of the basics for you - getting/setting, checking a field, setting an ID and outputing the information to an array.

In order to obtain a turing-complete programming language, that is, a language in which we can implement and execute any arbitrary algorithm, that is, that other turing-complete machines can execute too, we now need to add a way of (conditionally) branching, that is, the IF statement, and at least one way of repeating statements, that is the WHILE or the DO WHILE statements.

He includes a simple TL-based script as an end goal for the compiler to be able to execute and shows how to add rules for it to the lexer/parser. Rules for the "if" are relatively simple, but there's a hitch in dealing with embedded "while" statements he had to work around. The post ends with the bytecode results for the sample program and the resulting output from the compiled versions execution.

Templating is a real hot button in the web development community. [...] The high horses that people usually get on are that all too familiar TLA MVC (Model/View/Controller) architecture and "separation of presentation and business logic". The poor pedestrians upon which they look down are those who have written "spaghetti code" - templates where presentation logic, markup, business logic, database access configuration and whatever else you might imagine are mixed up in the same file. Well, I've got some news for you: you're all wrong.

He points out that, with most of the major templating tools out there, there's most people still put some sort of business logic in their templates. Rarely will you find a "pure" template that only echoes out the data. He gives an example of a Mustache template with "empty" logic in it. He shares a new term his coined too: "Template Animation". This is the separation of the templating process as it is usually done and splitting it so that the output is a modified DOM resource rather than a static template.

He talks about some of the advantages of this approach and an example of its use in an example of a logged in user vs not logged in user as well as a brief discussion of Markdown/HAML.

The only thing that Template Animation advocates is that the technological barrier between the frontend and the backend is never crossed - that our templates are truly logic-less.

There's lots of comments on the post already - everything from support of the idea to systems that already implement this sort of idea to disagreeing opinions.

The world of technology is riddled with inhabitants who treat tools as if they were religions. OOP, unit tests, patterns... these are all instruments that are supposed to make some jobs better, and not theological formulas that will magically make every single line of code written on the face of the Earth better. And yet, the vast majority of people treats them like they are, sparking everything from language wars to endless-and pointless - discussions on whether a particular technique is better than another.

He goes on to say that the tools developers use every day aren't just limited to the technology that makes them up. They're there to make things easier, but if the developer using them doesn't take the time to engage their minds to use them correctly, they're practically useless (100% code coverage, for example). He shares his three reasons why he thinks this issue is so wide-spread and the steps he suggests to push out of this way of thinking and back into a more mindful, thinking sort of development path.

The most simplest reason for this is the idea that annotations are markup. They mark (or, to keep the notion, annotate) code as being special or to be treated in some special kind of way, depending on the scenario where the code is used in. [...] From a design point of view this makes it clear why annotations should not contain logic. If annotations contain parts of such logic, it becomes splitted and possibly cluttered throughout different classes.

He goes on to talk about a second reason why he doesn't think they should be considered first-class in an application - it doesn't promote code reuse. For example, if you define them on a method, there's no way to use that method without them. He puts this into the perspective of the Stubbles framework that currently uses them and how he's changed the logic to live in special classes instead. He considers other changes like places annotations can be used and having different annotation classes.

Exception handling in PHP is not a new feature by any stretch. In this article, we'll discuss two new features in PHP 5.3 based around exceptions. The first is nested exceptions and the second is a new set of exception types offered by the SPL extension (which is now a core extension of the PHP runtime). Both of these new features have found their way into the book of best best practices and deserve to be examined in detail.

Some of the features he talks about were pre-PHP 5.3, but the focus is largely on these new features. He gives a bit of a background on exception handling in PHP and how custom exceptions could be thrown. He then moves on to the new features - first nesting exceptions and then some about the new core exception types (found here). All that being said, he includes some code to show the dynamic/logic/runtime exceptions in action including a look at best practices in library exception handling.

So far, we've done quite a bit of work on our Twitter class, making it better. There's still work to be done, though, especially improving the logic. The Twitter class we have now has a number of logical flaws in it that we need to address. Additionally, there are some logical flaws that we started with that I want to highlight, even though we've already fixed them. Let's get started with those.

He looks at a few things like setting the host name as a property, using the return of the HTTP request and handling exceptions (like when Twitter's down). The resulting code is included.