I recently needed to merge several topic branches into a client’s staging branch, starting the process apparently before I drank enough morning coffee and wound up with a pretty nasty set of merge conflicts. The conflicts came about because I merged the branches in an improper order, starting by merging a branch which was based off the other branch that additionally required merging, winding up with a mess that looked like this:
$ git merge add_client_comments_83612372 Auto-merging db/schema.rb CONFLICT (content): Merge conflict in db/schema.rb Auto-merging app/views/specifications/show.html.erb CONFLICT (content): Merge conflict in app/views/specifications/show.html.erb
Fortunately, undoing a Git merge containing conflicts you’d rather avoid is pretty easy. Begin by reviewing your recent commits:
$ git log --oneline -n3 6c1557d Merged branch add_comments_83612372 0fd0892 Merge branch 'editable_82327726' into staging c07eca0 finish with edits to top nav
I want to revert back to the commit associated with
0fd0892, and so I’ll next execute
reset, identifying the commit SHA:
$ git reset --hard c07eca0 HEAD is now at c07eca0 finish with edits to top nav
With that done, I can begin the merge process anew.
The bottom line on this matter is that Git can be a bit scary at times, however when circumstances such as the above arise it’s a certainty you’ll be able to deal with them in a sane fashion; just be sure to do a bit of homework before executing any commands which deal with effectively destroying uncommitted data, because once that data is gone it is gone forever (or until you rewrite the code)!
I spend a great deal of time writing about Web development, either working on books or writing for online publications such as Developer.com, PHPBuilder.com, JSMag, and TechTarget. So much time in fact that in 2010 I penned more than 130 articles. Many of these articles focused on PHP-specific best practices and productivity, two topics which should resonate closely with anybody involved in building websites for a living.
So I thought it would be useful to compile a list of the sixteen tutorials which touch upon these topics. In this list you’ll find tutorials introducing testing, debugging, advanced object-oriented features, code profiling, security, enforcing coding standards, and more.
Many novice developers tend to view object-relational mappers (ORMs) as a panacea to all of their database woes, marveling over features such as the convenient object-oriented syntax and magic finders. While there’s no doubt these are pretty cool features, any project of even moderate complexity will quickly exhaust such conveniences, requiring the developer to rely upon more sophisticated approaches to data access. For instance, what if you wanted to use the Haversine formula to calculate the number of registered users which reside within a 15-mile radius of the currently-logged in user? Certainly this isn’t a feature built into the typical ORM, meaning you’ll need to write a custom query to do the job.
Which brings us to the point of this article: where should this query be managed? Because Doctrine 2 treats models as POPOs (plain old PHP objects), it is easy to presume the query should be made available as a method within the model. Don’t make this mistake! Doing so would pollute your application models with database-specific functionality, which is precisely what Doctrine (and most other ORMs) are attempting to avoid altogether. Instead, you can associate a custom repository for each entity, and place the custom query code in the custom repository.
MySQL’s InnoDB storage engine supports the use of foreign key constraints, which are very useful but require you to manage your data in a much more rigorous manner than might otherwise be employed when not taking advantage of this feature. For instance, when migrating data from a database which does not use foreign keys to one which does, you’ll often encounter an error in which MySQL complains about a foreign key constraint not being met. This is easily resolved by temporarily disabling foreign key checks before beginning the import, and then re-enabling them when the import is complete.
To disable foreign key checks, add the following line to the top of your import file:
SET foreign_key_checks = 0
You’ll of course want to re-enable foreign key constraint checks following the import, so add the following line to the end of your import file:
SET foreign_key_checks = 1
When creating user registration and password-related models you’ll likely need an easy way to compare the user’s chosen and confirmed passwords. Yet despite the Zend Framework having long supported over two dozen input validation features, it wasn’t particularly easy to compare input associated with two different form fields without breaking tier separation best practices. That all changed with the Zend Framework 1.10.5 release, which finally added support for this useful feature.
Support was added by refactoring the Zend_Validate_Identical validator. By passing an associative array into the method containing a key named token which is assigned the name of the form field you’d like to compare, you can ensure that the user input associated with these two fields is identical. Here’s an example:
$pswd = new Zend_Form_Element_Password('pswd'); $pswd->setLabel('New Password:'); $pswd->setAttrib('size', 35); $pswd->setRequired(true); $pswd->removeDecorator('label'); $pswd->removeDecorator('htmlTag'); $pswd->removeDecorator('Errors'); $pswd->addValidator('StringLength', false, array(4,15)); $pswd->addErrorMessage('Please choose a password between 4-15 characters'); $confirmPswd = new Zend_Form_Element_Password('confirm_pswd'); $confirmPswd->setLabel('Confirm New Password:'); $confirmPswd->setAttrib('size', 35); $confirmPswd->setRequired(true); $confirmPswd->addValidator('Identical', false, array('token' => 'pswd')); $confirmPswd->addErrorMessage('The passwords do not match');