In Part 2 we're going to talk about presentation of the pitch you put together for this change. It's important that your pitch be well researched and in some regards provable, as the Agent of Change the responsibility lies with you to prove the value of your idea. As we touched on in Part 1, a well thought out plan is going to go a long way in breaking down the barriers that make change difficult to take hold.

He makes a strong point that you need to identify the problem you're trying to solve (and what solution you're wanting to propose) clearly before trying to present it to a listening audience. He recommends quantifying your solution in terms everyone can understand like "hours of work" or cost. He recommends coming up with a short "elevator pitch" version to entice and the longer version to fill in the gaps.

You've got slides, documentation, statistics and loads of other good information that is going to benefit your development process, sales people in particular are looking for that jewel that helps set your organization apart; you've got that jewel!

Writing code, which is easy to change is the Holy Grail of programming. Welcome to programming nirvana! But things are much more difficult in reality: source code is difficult to understand, dependencies point in countless directions, coupling is annoying, and you soon feel the heat of programming hell. In this tutorial, we will discuss a few principles, techniques and ideas that will help you write code that is easy to change.

He covers some of the good OOP principles to think about when developing - like cohesion, orthogonality and coupling (via class methods, polymorphism, dependency injection or interfaces). He spends some time looking at the SOLID development principles and how you can implement each of them in some sample code. He also talks some about high level design and how the separation of concerns can help make your code easier to maintain and change.

We all to make changes that make our jobs easier, so if your change isn't meeting a need or helping to ease a pain point, it's probably not the right change. [...] Find something that makes your job harder or less enjoyable, there's a pretty good chance that you aren't the only one.

He recommends doing plenty of research before making your recommendations, especially if it's a "we should be doing, but don't know how to" kind of improvement. He uses test-driven development in his examples, with part of his pitch being that it reduces the number of bugs that make it into production.

When plans are well thought-out and researched, the element of risk that others perceive tends to dwindle. [...] It's not about pointing out the faults of others in the organization or assigning blame, it's about learning and making positive changes from the lessons you've learned.

The CakePHP core team is very exited to announce a major jump in the version numbering. CakePHP 2.0 stable is out! we have put endless hours into this release and great ideas have made it into the the framework for this version. [...] The overall CakePHP ecosystem has also been improved. [...] A huge thanks to all involved in terms of both contributions through commits, tickets, documentation edits, and otherwise contribute to the framework. Without you there would be no CakePHP.

Some huge changes have happened in this release including:

• Dropping PHP4 support
• Use of more native PHP functions
• PSR-0 compliance
• Object injection for libraries/components/helpers/etc
• Console tools completely rebuilt
• A move to PHPUnit tests (away from SimpleUnit)
• HTML support in form helpers
• Lazy-loading on just about everything making the overall experience faster
• Several new plugins like: DebugKit, Datasources, MongoDb, Migrations and AclExtras

They've created a few resources to help you get started with this new version including a new version of the book, a screencast and a migration guide.

The key issue was that 5.3.7 accidentally broke is_a() for a reasonably large number of users. Unfortunately the fixup release 5.3.8 did not address this 'mistake', and after a rather fruitless exchange I gave up trying to persuade the group (most people on mailing list), that reverting the change was rather critical (at least pierre supported reverting it in the 5.3.* series).

This new issue was causing some strange errors to pop up in his code because of a parameter type change in the is_a call, updating the first parameter to be an object instead of a class name. The is_a() call sends its requests to __autoload in some cases and the string->object mismatch of those parameters causes errors to be thrown. His workaround is, in your checking, just be sure to call an is_object first before passing things off to be is_a() checked and autoloaded.

Today a couple of hours back my site got compromised. Not much changes to the code, but the .htacces was changed and some code [...] was added to the .htaccess file, which redirected the traffic coming from search engines to a malware site. It has now been removed and to prevent any such changes to the .htaccess file in the future, I've written a small php script that compares the hash (SHA1) of the two major files that usually get compromised and compare them to the one originally stored.

It's not a preventative measure by any means, but it can help you keep track of if something's changed. Several issues have popped up in the major blogging engines that allow for changes to be made directly to files. These changes result in the sha hash to be different and can be used to trigger a security alert. His sample code shows a basic call to mail an alert, but it could be as complex as you'd like (possibly even logging to a database or the like).

The conference social will now take place at a venue called ClubNL, which is also in central Amsterdam and within easy walk from the Amsterdam main train station. Please remember to hold on to your conference badge, as you will need it to gain access to the event. For more details check out the updated social page on our website. We are hoping to see you all there!

There's still time for you to get your tickets to this great event happening in a few weeks (May 19th-21st) in Amsterdam - full event tickets run 695 Euro and the single-day tickets (just tutorial or just conference day) are 375 Euro. Get yours today!

The issue there is that this depends on the SQLite 2 library which isn't supported by upstream anymore for a few years. It was a logical step therefore to remove this extension from PHP trunk. The support for the sqlite3 extension and the PDO_sqlite driver (same link as above, read it carefully), which use version 3 of the library, are continued.

The change probably won't be happening in any of the PHP 5.3.x releases but should becoming in PHP 5.4 so, as he advises, you might need to rebuild your database file and change your application to correct things for the changes.

I need one MyISAM table in my schema, I'm using Symfony 1.2 and Propel 1.3. As flexible as Symfony and it's YAML files are, Propel currently doesn't allow you to change the storage engine on the fly. [...] So, the next best thing to do now is to have it so that when Symfony runs propel:insert-sql, I can piggyback my own SQL to it. Luckily, this is possible, and it's explained here.

He gives an example of how he's doing it - making a simple alter table script, putting it into a SQL file and pushing it out into the project's setup via a "propel:insert:sql" command.

After I had a quick look at the feasibility of this feature I spend some time on implementing it for Xdebug's HEAD branch that is going to become Xdebug 2.1. Variable modification tracing can be enabled by setting the php.ini xdebug.collect_assignments setting to 1. Of course this can also be done in either .htaccess or by using ini_set(). This setting requires general execution tracing to be enabled as well and it's only available for human readable trace files (the default format).

He gives examples of how two example scripts would be logged to the trace file - one inside of a basic function and another showing updates to the properties on a class.