Closures are a new language-level feature that has been added to php 5.3, along with namespaces, late static binding, and a slew of other new features, patches, and updates. If you’re like me, you might be wondering what the practical uses for these new features are before you can rightly justify diving in and using them in new or existing projects. I experimented a lot with closures and possible uses over the past few weeks, and came up with some compelling reasons to start using them.
I’ve spent the past few weeks here at work researching and playing with NoSQL databases (and especially MongoDB) for a new feature we’re developing that doesn’t easily fit into a relational model. And so far, I really like what I see. The profoundness of the shift away from the relational model and the implications that has just blow my mind. You no longer have to fragment your data to persist it . You just store it. That’s it. No more hours toiling over the design your table schema and how to break apart the data you put together just to fit it into a relational model. You can now store your data exactly how you use it in your application, with no other special needs or impedance mismatches. Going back to an RDBMS system now just seems illogical – it’s like breaking apart a camera tripod just to fit it in the same standard size case you’ve been using for years instead of just collapsing it and finding a different case that fits it better. All that effort you go though tearing down your tripod and putting it back together every time you use it is wasted and unnecessary. It’s a symptom of the larger problem that your case doesn’t fit your tripod. more
Once you fully get the NoSQL viewpoint and the implications it has on the future of data storage, you have one of those “why didn’t anyone think of this sooner?” moments. And yes, I know key/value stores like memcached existed long before this whole new “NoSQL” movement, but it’s not quite the same thing.
Object databases are an interesting case. They are in the “NoSQL” category and solve the same problem other NoSQL databases do – creating a storage mechanism that fits your data instead of making your data fit a predefined rigid storage mechanism. So why didn’t they catch on? What gives? It’s anyone’s guess why object databases didn’t catch on and achieve widespread adoption, but one thing is for sure – object databases really missed the boat while other NoSQL database technologies are running rings around them.
The primary problem is that most object databases are designed for a specific language, like Java or .NET. Some have more language support than others, but the problem is still the same – by integrating in directly with a language’s object model they depend on specific language implementations, which severely limits adoption. They solve the impedance mismatch problem that RDBMSes present, but fail to provide language-agnostic data persistence and access , effectively tying their use to specific technology stacks and platforms.
The Best of Both Worlds
NoSQL databases are gaining traction like no other database technology has in over 30 years. The reason is that good NoSQL databases solve both key data storage problems: impedance mismatches AND language-agnosticism. By storing the data in an intermediary format like JSON (or BSON) and allowing custom file content types, the focus is on the actual data itself instead of specific technologies or data models. The technology stack becomes irrelevant, and the walls to gaining user adoption crumble.
The bottom line is that NoSQL databases are not just the latest fad. They represent a fundamental paradigm shift in data storage and are an entirely new way of thinking about how to store and access your data in a way that makes sense for your actual usage. NoSQL databases are absolutely something you should be paying attention to and following closely – they are a strong contender to the RDBMS model
and will likely become the de-facto data storage choice for most new web applications within a decade and a solid alternate choice.
Multi-byte characters can cause quite a few headaches for the unsuspecting webmaster. Sometimes all you need to do to figure out how to fix the problem is detect which database records have UTF-8 data in them and which ones do not. If you’ve been scanning records manually, stop now. Here’s a quick query to cure your ales:
Return all the rows with multi-byte characters in table posts on field title:
SELECT * FROM posts WHERE LENGTH(title) != CHAR_LENGTH(title)
This does pretty much what it looks like: returns all the rows in the posts table where the title’s character length does not match the title’s length. This works because the
LENGTH function returns the number of bytes in the string, while the
CHAR_LENGTH function returns the number of characters in the string. If the string contains multi-byte characters (individual characters that are made up of more than one byte) like international UTF-8 characters, the two functions will return different numbers and will not be equal, thus including that row in your results.
PHP provides two built-in functions to retrieve properties of a given class – get_object_vars and get_class_vars. Both these functions behave the same exact way, one taking an object as a variable and the other taking a string class name. The tricky thing about the two functions is that they behave differently depending on the call scope, returning all of the class variables available within the called scope. So if you call either function within the current class you need properties from, all properties are returned – public, protected, and private – because the current scope has access to them all. This makes seemingly simple things like returning all the public properties within the current class a bit of a pain if you want to keep the code inside the class itself.
"… So a blogging platform won the content management system award? How sad is that?"
My knee-jerk "how sad is that?" reaction comes not because I don’t think WordPress is worthy, but because of what it implies about the state of other open source CMS projects. The reaction comes from the fact that a blogging platform is kicking your CMS’s ass in its own category.
Sometimes there are unique situations where you need to order query results by a particular field in descending order, but also need NULL values first. The default (and logical) behavior of MySQL in this case is to return NULL values last, because in descending order they have the lowest value (none). But what if you really need to reverse this and force NULL values to the top of the result set?
I was fortunate enough to be selected as the regional speaker for the Dallas CodeWorks 2009 stop by the Dallas PHP User Group through a community voting and selection process. My talk was entitled Object Oriented Apologetics , and was essentially about letting people know what good object-oriented code is, when to use it, how to use it, and more specifically why to use it over traditional procedural PHP code. more
Object Oriented Apologetics
In defense of object-oriented programming – How and why you should use object oriented programming for your next project.This talk is for PHP programmers who are just learning about object oriented code, who cling to old excuses("object oriented code is slower"), or who are otherwise unconvinced of its usefulness. Concrete real-world examples of commonscenarios and challenges that programmers face will be presented, and how taking an object oriented approach is better than a proceduralone in most cases. Copious code examples in both object oriented and procedural approaches will be provided throughout, and thedifferences and benefits of the object oriented approach will be explained.
If you were in the talk, please rate it on Joind.in
The CodeWorks Experience
All in all, the CodeWorks roadshow Dallas stop was much smaller than I expected. There were about 20 people in the talk I gave. I suppose it was both a good a bad thing. On one hand, I had a lot of fun connecting with the other speakers and attendees on a more personal level than I would have had the opportunity to do otherwise. I met a lot of new people in the PHP community that I will probably stay connected with on some level, even if it is just Twitter and IRC. We had a lot of fun the night before the presentation day eating together and hanging out.
On the other hand, I know that as a business, the relatively low attendance levels coupled with the high travel expenses could mean that something like this can’t happen again, which is a shame. This was one of the best efforts I have seen in a while to really lower the price of the conference for attendees by bringing the speakers directly to their cities or at least ones that are close by. Going to ZendCon, for instance, could easily cost up to $2,500 for the whole trip with airfare, hotel stays, and food, if not more.
The bottom line here is that CodeWorks was a good conference that offered a great value for your money. I had a great time meeting and connecting with new people and finally meeting people in real life that I had been communicating with for years. I learned some new things and finally got the kick in the pants I needed to jump into Test Driven Development, thanks to Jason Sweat’s TDD tutorial and hand-holding.
Now I’m just looking forward to php|tek in May 2010.
When debugging, I often find that I have to comment and un-comment a block of code several times during the process of trying to find out what’s going on. That used to mean typing and deleting comment block characters repetitively, but not anymore. Here’s a simple solution to that problem: Comment or un-comment an entire code block of code by typing or deleting a single character.
I was able to arrive at this solution by combining the one-line comment with the comment block in a way that takes advantage of the rules the different types of comments have to follow.
Prepared statements differ from normal queries in one major way: Instead of sending one SQL string with the values defined by single quotes in one package, the SQL string and values are sent in two separate calls. Prepared statements themselves are like query blueprints, with placeholders where the values will go. The query values are sent in a separate call with a reference to the prepared statement, and are dropped in place and executed.
This post approaches the problem and presents a solution from a PHP angle, but even if you’re not a PHP developer, you should be able to follow along with some creative substitution.
The Old Way
Prepared statements take longer because they are 2 round-trips to the database for a single query. As soon as you prepare a query, it’s sent to the database with the placeholders you set. So the database engine takes that prepared statement and maps out the query and optimizes it for execution. Then when you call execute() only the values you give are sent to the database, with a reference to that query you just prepared. The database engine drops in the values and runs the query. This is totally immune to SQL injection, because the database engine already knows exactly where the values begin and end (the placeholder marker(s) you set), and therefore never need escaping. The reason SQL injection exists in the first place is because the entire query is interpreted upon execution, values and all. So if anything interferes with the quotes surrounding your values, the engine thinks that value has ended and thus a security hold is introduced. That problem is avoided all together with prepared statements by letting the database engine know ahead of time exactly where to put each value you pass to it later on. There is no need for escaping and there is no need to worry.