PHP 5.3 is out and is moving from “a nice toy to play with” release into a production ready version of PHP. I for one am ready for this to happen. PHP 5.3 has some really great improvements that will empower programmers to do rock-star level stuff. Here are three things that I’m itching to use.

Name Spaces
I can’t think of a more wonderful thing to come to PHP. Right now I have to create class names that look more like paragraphs than anything else. Here’s a little (fake) example.

LB_ContentManagement_Helper_Validation_SpecialCharacters::ReplaceAmpersand($content);

In order to have an __autoload() function we need to have class names that also represent where the file is found. It makes for all kinds of goofy class names. I’m looking forward to the day when I can just state the namespaces I’m using and then call the class like this

SpecialCharacters::ReplaceAmpersand($content);

Late Static Binding
This is a complex issue with many implications. One of those implications is that you can now call a static method from a variable like so.

$className = "Users";
$methodName = "Login";

$className::$methodName("bob@domain.com","password");

Prior to PHP 5.3, this wasn’t possible. You had to instantiate the class, then call a public method to do the same thing. Now you can call a method outside of the context of strict inheritance. In the above example you could set a different method for different types of logins, such as an admin login vs. a site user. Not the most practical example, but it gives you an idea of what you can do.

Anonymous Functons
Anyone who has done anything with JavaScript will know the power of anonymous functions. They empower the programmer to create a function that can be used as a callback. Here’s an example.

function doStuff($arg1, $arg2, $callback)
{
    // do something with the arguments

    $callback();
}

doStuff("1", "2", function() { echo "we just did a callback"; });

In the above example, the call to the function “doStuff” contained an anonymous function. This was then called within “doStuff” when all the processing of $arg1 and $arg2 was finished. This methodology has been a life saver in JavaScript, especially with jQuery, and I’m glad to see its arrival in PHP.

These and other features are moving PHP forward. I can’t wait until PHP 5.3 is adopted as the standard so that these new features can be turned into great applications.

More minute methods to further improve your database performance

“Schema Busters” is a multipart technical overview of Database Design elements that you can implement when designing and accessing your database implementation. In this third section we will discuss several tricks and tweaks to consider when constructing your database schema and queries. While some of the proposed methods are fundamental and globally applicable, others are subject to a lot of debate since they are highly situational. Take the application logic into careful consideration before utilizing these methods since some of the proposed methods can actually work to the detriment of your system. The examples below are intended for a MySql implementation, but I am confident that similar issues can be resolved in a similar fashion for other database engines. With that said let’s begin with an extremely MySql specific concern.

MySql Storage Engines and the COUNT Function
While administering your database you may have noticed that MySql has two primary storage engines: MyISAM, which is good for read-heavy applications, and InnoDB, which is good for write-heavy applications. In general the two have similar performances with the one exception being how they handle the COUNT function. Before I begin discussing the benefits of using MyISAM’s meta-data collection, I would like to remind readers that InnoDB has considerable benefits when creating an insert/update heavy application which is common in several company intranet applications. Since a large majority of lifeBLUE’s projects involve front-facing websites wrapped around a back-end management utility, we frequently utilize the MyISAM engine over InnoDB.

MyISAM keeps an internal cache of table meta-data whereas InnoDB keeps no such cache. One of the values found in this table meta-data is the number of rows, which in turn means any COUNT(*) call has the potential of having minimal costs. InnoDB, on the other hand, has to read every entry row present in a table to evaluate a COUNT(*) call (which is about as effective as calling SELECT(*) on the table). The major drawback to utilizing MyISAM is the loss of InnoDB-specific functionality such as stored procedures.

Subqueries vs. Joins
For those who are unfamiliar with the terminology, Subqueries involve the embedding of queries in another query, most commonly in the form of SELECT statements, while a JOIN operation creates a temporary table that holds results from two different tables linked by an identical value in both tables. Two example queries with the same results are provided below:

• Subquery:
  SELECT d.Id, (SELECT alias FROM resources r WHERE r.Id = d.Id) AS alias FROM document d
• Join:
  SELECT d.Id, r.alias FROM resources r INNER JOIN document d ON (r.Id = d.Id) GROUP BY r.Id

A general rule of thumb is to replace correlated subqueries with joins. A correlation occurs when the subquery references a table from the outer query. In our example, the subquery can be considered correlated since it references the d.Id property from the document table which is contained in the outer query. It is also important to point out that implied JOIN operations are not as efficient as explicit JOIN operations since the join condition is not specified immediately resulting in larger table reads. Above we utilized an explicit JOIN operation and below we show an example of an implicit JOIN operation:

• SELECT d.Id, r.alias FROM resources r, document d WHERE r.Id = d.Id

If you want to take it a step further, really crack down on the type of joins being utilized to reduce the size of returned datasets (types of JOIN operations explained here).

Table Partitioning
This practice requires a strong understanding of the application logic, and should be evaluated from both a usability and development standpoint. There are two approaches to table partitioning: read-optimization and write-optimization. Let’s start with read-optimization:
The idea is to simply maintain a smaller dataset of frequently accessed data and another table to hold infrequently accessed data. Imagine that you have an extremely generic content management system where each page contains an alias, description, url, and html body with the following table layout:

CONTENT

The alias and description are simply to give a name and summary of the content and the url is obviously the page location. The HTML body will most likely only be accessed when the page is called directly, whereas the alias, description, and url may be displayed in search results and recent item listings. Our resultant tables would look like this:

CONTENT_FREQUENT

CONTENT_INFREQUENT

For write-optimization we are implementing the same exact practice, just with the understanding that we are separating the frequently updated values of a table from the infrequently updated values.

Data Types & Size Constraints
There are several ways to tighten up your data usage by manipulating size constraints and data types. I will provide a few examples and leave the rest to the imagination. By now you should understand that VARCHARs maintain a variable length byte to keep track of how many characters are contained in the VARCHAR entry. If we are handling data entries that have a known fixed size, such as zipcodes, it is beneficial to use the CHAR data type as opposed to a VARCHAR since we are eliminating the need of the length determining byte. This may seem small at first, but after a thousand entries we are effectively eliminating a kilobyte of additional data. The worst memory hits come in the form of redundant data entries. It is important to implement proper database normalization to reduce redundant entries as well as other undesirable attributes. See my first Schema Busters entry for more information on database normalization.

Conclusion
If you have been following along from the first entry in this series you should now have enough information to crank out an extremely clean and efficient database design. If there are areas that still remain grey, I highly recommend picking up a textbook on database systems such as the Fundamentals of Database Systems by Elmasri & Navanthe. Also be sure to check back for future entries on improving database and application efficiency. From this point on we will be moving into application-level concepts to improve efficiency and promote usability. Any additional related database entries can be expected in the form of an addendum.

In our office, we have a constant debate about traditional “webby” design vs. “conceptual” design. I would like to set the record straight, by saying your website absolutely, positively, 100% guaranteed, does NOT have to look like a website.

When you think of a website, what do you think of? Lines, boxes, solid colors, horizontal navigation, and the occasional drop shadow? Structure, structure, structure. Sounds fun and innovative, right? Not.

Your website is representing YOU. So don’t you want it to be as awesome as you are? Are you square? Probably not. Are you boring? I hope not. Are you a solid color? Doubt it. So why does your website have to be? Think of it more like a digital self portrait.

Take your website on a walk along the beach, back in time to black and white TV, in the middle of a rock concert, on a deserted island, you name it, we can do it.

Don’t be afraid to break the mold. Its 2010, lets scrap the straight lines, symmetric text, and get with the times. We’re all sitting around lifeBLUE dying to be the ones to take you to that next level, all you have to do is give us the green flag!

We know the design lingo, but the chances of you visualizing in your head, what we have in ours, is probably slim. (warning, you probably wouldn’t want to either). So let’s break it down in a visual way to help you see what the possibilities are, from a few companies that turned the heat up a notch:

So from our team to you… Please, challenge us. No really, I dare ya.

Are You a Web Designer?

It seems our industry is in the middle of a conundrum as to what one should call themselves when asked the pivotal question of “what does your company do?” The easiest, most laymenesque answer is “web designer” and for 99% of the U.S. population you would get a nod of understanding. Now to the more experienced audience this term seems very arbitrary. Does that mean you design only? Do you program applications? Do you offer marketing? (Fill in Blank of any other website related profession/service) etc., etc., etc. If you sell cars, you are car dealer? If you sell landscaping services, you are a landscaping company. It just seems like it should be so simple. To the point of this blog lets just take a gander at the various names circling the industry and what they could possibly mean just for fun’s sake.

Web Designer - This term would typically reference an individual, perhaps a freelancer. In most cases this person wouldn’t just “design only”, rather possess some basic HTML skills so they could actually put together an entire basic website. Anyone that actually does only design would probably refer to themselves as a Graphic Designer.

Webmaster - This term is a bit outdated, but there still is a high demand for it. A Webmaster is simply the person you call to keep your website up to date, fix, etc. Basically a Webmaster is hired to let the world know that the entity behind the site is still breathing. In most cases the Webmaster is the Web Designer who built the site to begin with. Now do you see how this works?

Web Developer(ment) - This term would insinuate that the company/individual has some application programming abilities in the form of PHP, .NET, Java, or God forbid some other type of painful, archaic language. Skill can very extensively, but nonetheless you should at least get these guys to build you a “hello world” application.

Interactive Agency - An Interactive Agency (at least a real one) is typically going to be your high end, full-on, online marketing campaign company. They typically use various forms of media and promotional techniques to turn a website into a marketing juggernaut, of course, that is if they are good.

Web Agency - A Web Agency is a company that has progressed by truly combining the graphic design, web designer and web developer skill sets and can internally produce anything that can be done specifically for the web. While this type of company may specialize in other services such as Internet marketing, they have their roots in traditional web development.

So you’re a l337 php coder. So you’re using classes to make things awesome… and you are also tired of including every single file you need. You don’t want to, but you end up loading every bit of your application with a huge list of includes, even if you don’t need all of it.

In comes the PHP class autoloader magic function.

__autoload($className) {
    // Your awesome code here
    require_once($classPath);
}

As you might expect there are many ways to auto load classes. lifeBLUE has their preferred method. However, there are times that you want to have more than one class autoloader for different situations. Our current application actually has several ways for loading classes in. This presents a problem, as the autoloader can become a complicated mess. Thankfully there is a nice little function PHP provides us that makes these problems go away.

// Awesome PHP autoloading register function
spl_autoload_register("FunctionNameOne");
// Calling a static class function
spl_autoload_register(array("ClassName", "FunctionNameTwo"));

Once you have registered your functions, you can write them to include your class in whatever method you choose. For more reading check out the PHP site for the documentation.

Using this allows you to have more than one autoloader present in your application. It also allows you to have your own autoloader function co-exist nicely with autoload functions from libraries you get from third parties.

Happy including!

The importance of Database Indexing and its effects on efficiency.

“Schema Busters” is a multipart technical overview of Database Design elements that you can implement when designing and accessing your database implementation. In this second section we will discuss the importance of Indexing database columns to speed up data accesses. We will discuss the pros and cons of indexing, and describe the logic behind Indexes.

What is an Index?
Think of database indexes like you would an index in a library book. When you go into the library and need to find a book of a particular genre, you usually head straight to the genre’s section. This is similar to performing Select statements on non-indexed tables. You might be looking at the right shelves but you don’t necessarily know where to start looking. Indexes help to more quickly identify the location of a book, or in the case of databases a record.

How do Indexes work?
Take our library example from above. What would be an efficient and simple solution to help speed up the time it takes to locate a particular book? Sorting! Let’s sort all of the books by their title, and now anybody who knows the title of their book can quickly slim their search down to a significantly smaller number of books. Database indexes work in the same exact way. Indexes keep track of a sorted set of values with an associated row number that allows them to point back to the original record containing the sought index value.

Creating an Index
You can create an index on a table column either at table creation or by using the CREATE INDEX syntax. Listed below are examples of both of these approaches on the same table with the same results:

• CREATE TABLE Settings
  (
  settingId INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  settingName VARCHAR(128) NOT NULL,
  settingDescription VARCHAR(512) NOT NULL,
  settingGroup VARCHAR(256) NOT NULL,
  settingValue VARCHAR(512) NOT NULL,
  INDEX(settingName),
  INDEX(settingGroup)
  );
• CREATE TABLE Settings
  (
  settingId INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  settingName VARCHAR(128) NOT NULL,
  settingDescription VARCHAR(512) NOT NULL,
  settingGroup VARCHAR(256) NOT NULL,
  settingValue VARCHAR(512) NOT NULL,
  );
  CREATE INDEX indexSettingName ON Settings (settingName);
  CREATE INDEX indexSettingGroup ON Settings (settingGroup);

Efficiency Comparisons
Indexes manipulate the fact that they are looking through sorted records in order to refine their search scopes to specific regions by doing simple comparisons. While the method that indexes refine their search scopes is dependent upon the DBMS and the type of Index being created, we can still show a generic example of efficiency improvements due to indexing based on the concept of binary searching. Keep in mind that this is a rudimentary example of indexing logic and is simply an estimate of efficiency gains. Again we will refer to our library example when determining efficiency gains. Let’s assume that the number of books contained in this non-indexed library is N, where N is any real whole number greater than 0.

Imagine that you are looking for a particular book in a non-indexed library. Where do you start? Best case scenario is you will pick up the book you want first, however in the worst case scenario you could end up looking at every single book before finding the one you want. This yields a best case of 1 comparison versus a worst case of N comparisons.

Now imagine that you are looking for the same book in an indexed library sorted by book title. We can now logically eliminate half of the books to look through simply by comparing the middle book title with our sought after title. In one row comparison we have halved our search time, and the greatest part is this process can be applied recursively! This yields a best case of 1 comparison versus a worst case of log2(N) comparisons. The logarithmic base of 2 comes from our division into two subsets equivalent in size.

First let’s note that in the best case we gain nothing, however efficiency is better evaluated in the worst case or in an aggregate of the two. In the worst case we considerably reduce the amount of books we will have to look through. If you are familiar with Big-O Notation you will notice this difference immediately. If you’re not familiar with Big-O Notation, try substituting 1,000 for N. Our non-indexed library has a worst case of 1,000 searches whereas our indexed library has a worst case of approximately 10 searches. It takes 1% of the time to find the book we want in the non-indexed library (if we’re considering the worst case scenario)!

Side Note
If you have been using databases for a decent amount of time you have probably already come across indexes but may not be immediately aware of it. Primary Keys and Unique constraints are actually forms of indexing. By default these indexes are clustered, but you can specify otherwise when creating the constraint. This is important to note when deciding how to define primary keys for your tables.

Index Issues To Consider
Indexing is only beneficial to access queries, so before you go and add indexes to all of your tables on every column possible know that indexing can have a negative effect on your database performance. Indexing columns will increase the time it takes to perform INSERT, UPDATE, and DELETE commands since the index will also need to be modified appropriately to reflect changes. Always ask yourself “Will the majority of activity on this table be SELECT statements?” and “Where do I want to see stronger performance?” before adding indexes to a table.

It is also necessary to consider which columns you wish to index. Take our library example again: If we knew the author’s name but not the book title, then we would gain no benefit from an index on book titles. We would need to add an index on the author attribute instead of the book title column. In all reality you would probably benefit from an index on both attributes, but it is hard to understand multiple indexes with our library example since we cannot sort books by author and title separately due to physical limitations of the books. Fortunately there are no physical limitations with database data so it is entirely plausible to have two separate and distinct indexes. Choosing which columns to index is highly dependent upon project and client specifications. If you are having trouble identifying where you need to insert indexes consider using a database analyzer that can track where you are experiencing the most transaction traffic and provide suggestions that may benefit your database design.

Conclusion
Almost every project you come across can benefit from indexing database tables. Learning how to properly create indexes and utilize them to your advantage can further increase their usability, and the best part is they are relatively simple to understand and implement. Indexing is one of the primary means of boosting application speed, especially with a database-heavy application. For more information on indexing consider picking up Fundamentals of Database Systems by Elmasri & Navanthe or another database schema textbook.

A few bold and daring members of the lifeBLUE team have decided to embark upon a great adventure…cleansing their bodies! Everyone knows that we, as a nation, are in the middle of a Food Revolution with recent thought provoking movie/books such as Food Inc and Fast Food Nation, and the LB is no different. Five noble team members have embarked upon this valiant quest filled with yummy shakes, delicious fruits and vegetables, and enough pills to choke a majority of small animals. On the first day of the cleanse we have suffered our first casualty (Note to Self: If you refuse to eat vegetables, fruits, brown rice, or drink protein shakes, this might not be a good diet for you). With that being said, the other four are still going strong with the exception that one person hasn’t started yet because they somehow don’t think they will be able to control themselves on an upcoming visit to New Orleans…good call.

How did the LB get started on the cleanse? Well truth be told one of our clients, Watters Creek Chiropractic, located not 500 yards down the road from our office has included overall health and wellness in their list of services as part of their effort to promote a healthy America. They are helping the LB along on their mission providing their expertise making the shakes tasty and likewise coming in to make a few shakes for the team. Thanks WCC!

All in all the 21 Day Cleanse is a good way to promote a different way of eating and likewise force us to commit to a system that doesn’t allow the bad food choices we are faced with each and every day. Hopefully we will be better citizens and web designer/developers when it is all said and done. If we’re not then we will at least decrease the gravitational pull on the earth by being 10% lighter. For more information on the 21 Day Cleanse and Watters Creek Chiropractic, visit their blog.

It’s no secret we love jQuery here at lifeBLUE. It’s made our life easier and our applications better. One task I find myself frequently doing is finding something nested within the tag or element I’m working with. For example.

<div id="iKnowAboutThis" >
    <div class="one" >One</div>
    <div class="two" >Two</div>
    <div class="iWantThis" >Three</div>
</div>

I know all about the div element with the id of “iKnowAboutThis”. I can get at that with a simple:

var iGotIt = $("#iKnowAboutThis");

I can use the jQuery object to do whatever I want. But what if I need to get at the element with the class “iWantThis” that is nested within “iKnowAboutThis”. If I have more than one on the page then I can’t just do this:

var iGotThis = $(".iWantThis");

If I do the above, I’ll get all of the elements with that class. All I want is the one nested within “iKnowAboutThis”. Fortunately, jQuery has a very powerful tool to help me.

By using the context option within the jQuery selector I am able to get at any nested item I want like this.

var iGotIt = $("#iKnowAboutThis");
var iWantThis = $(".iWantThis", iGotIt);

With that little snippet, my search for elements with the selector I specify stays within the context I set for it.

There you go, simple!