Tag: CakePHP

CakeFest 2014 : a look back

Disclaimer:  I’ve written this post a few days after I came back from CakeFest 2014.  Unfortunately, it is unfinished, and by now I have completely lost hope of ever finishing it.  My main excuse is that the first day after CakeFest was my first working day at my new job, which completely and totally consumed me for a few months.  And now, it seems like CakeFest 2014 was a few decades ago.  Mostly I wanted to do two things here: list all the talks with videos and slides, which has probably been done by other people by now, and tell everyone that this was one of the best events I’ve ever attended.  For those who haven’t been to one, I strongly recommend getting a ticket to CakeFest 2015, which will take place end of May in New York, USA.  End of Disclaimer.

 

It’s been a week since I came from Madrid, where I’ve attended CakeFest 2014, a conference dedicated to CakePHP framework.  Now that I’ve caught up on sleep, calmed down, and cleared out my mailbox, I have a few minutes to look back at the event and share my thoughts and impressions.

CakeFest2014

For those of you who are too busy to read the whole thing, here’s the executive summary.  I had very high expectations of the conference way before I went.  I knew there will be one or two core developers.  I knew that there were previous events before.  And I do usually expect high quality stuff from the CakePHP community.  But as I high as my expectations were, the event went through the roof!  It was an absolutely amazing couple of days, where I met a lot of cool people, learned a lot, and had plenty of fun!  If you missed this year’s conference and you are involved in any shape or form with CakePHP, make sure you attend the next year one.  Start making your arrangements now.  You can thank me later.

Now for the long story…

Continue reading CakeFest 2014 : a look back

PHP tags – once and for all. Yet again.

For those of us who have been using PHP since the early version 3 days and such, here is a modern day refresher for PHP tags:

If a file is pure PHP code, it is preferable to omit the PHP closing tag at the end of the file. This prevents accidental whitespace or new lines being added after the PHP closing tag, which may cause unwanted effects because PHP will start output buffering when there is no intention from the programmer to send any output at that point in the script.

And from the comment on the same page:

Since PHP 5.4 the inline echo <?= ?> short tags are always enabled regardless of the short_open_tag (php.ini) setting.

For me personally, closing PHP tags are a part of muscle memory.  I’ll have to unlearn that, I guess.  And in regards to the inline echo tags, I was under the impression that they are being phased out together with the other short tags (<? … ?>).  Apparently, I was wrong.  They are here to stay.  Which explains why there are in PSR-1, PSR-2, and in CakePHP 3 (which requires PHP 5.4.16 and fully adopts PSR-2) in particular.

Compatibility Breaks in CakePHP 3.0

Mark Story goes over a few reasons of why CakePHP 3.0 breaks compatibility in this blog post.   If you are working with CakePHP or involved in any large system that lives forever, you should read those in detail.  Otherwise, here is an overview:

  • PHP has changed
  • Ideas that didn’t work out so well
  • Outdated implementations
  • Improve consistency

Also, if you are working with CakePHP, you should attend the CakeFest 2014 event next week in Madrid, Spain.

CakeFest 2014 at Madrid, Spain during August 21-24

I am seriously considering going to CakeFest this year.  Madrid is not too far away to fly to.  The event takes place over the weekend, so work stuff can be easily arranged.  And it doesn’t cost too much – a 2-day conference with the 4-star hotel is only $480 USD (early bird prices until July 15th).  That alone is a good deal.

But looking at the schedule, it’s even more tempting.  The upcoming CakePHP v3 coverage, advances queries, testing, debugging, profiling and optimization, using CakePHP with Composer, Twitter Bootstrap, Travis CI, Selenium, AngularJS and more – these are just some of the subjects that will be covered.  And the speakers are on par  including core developers, community leaders, and otherwise interesting people.

CakePHP 3, here we go again.

As some of you might know, I’m a big fan of CakePHP framework.  I’ve used it on numerous projects since the beginning of times.  I’ve built projects small and large, migrated existing native PHP codebases to CakePHP and even survived a few major CakePHP upgrades – 1.2 to 2.0 comes to mind.

Currently, I am at the start of a couple of projects, which require a bit of the future support.  CakePHP 2.x can handle the job now, but I’m looking more into the next 3-5 years.  And that’s why I’m looking at CakePHP 3, which is still in the early development stage, with an alpha release coming not too long from now (have a look at the CakePHP 3 roadmap document).  Let’s have a look at the high level goals for CakePHP 3:

CakePHP 3.0 represents a significant break in backwards compatibility. One of the largest the project has ever had. We are trying to modify existing methods and classes only where it is required. However, modernizing the ORM has caused a significant ripple effect in other parts of the framework. When making changes we are working towards a few goals:

  • Adopt broader PHP community standards. Tools like composer, and PSR-0, PSR-1 have proven to be useful tools for improving interoperability. CakePHP should embrace these community standards where possible.
  • Increase modularity. CakePHP has had history of being tightly coupled. We’re trying to reduce coupling and make more standalone libraries. For example the new Collections library, and Events system have no dependencies on the rest of the framework.
  • Use PHP 5.4. When we started on CakePHP 3.0, this seemed ambitious. However, with the release of PHP 5.5, and impending release of PHP 5.6, it feels right on target now.
  • Modernize and simplify the framework. CakePHP has accumulated numerous features over the years. By removing some features that are better implemented as plugins we make CakePHP simpler and smaller for everyone. Separating features into plugins allows greater community involvement and more rapid iteration on features.

That sounds like a lot.  In times like these, migration guides are useful.  With no code to migrate, such documents help migrate the knowledge. They usually answer the questions of what changed, what new stuff was added, what was removed, and where, in general, this whole thing is heading.  Reading through the migration guide, here’s what I picked up for myself:

  • CakePHP 3 supports Composer.  This is a very welcome change!
  • All of the source code has been reorganized to support PSR-4 autoloading specification.  Yes, that means changes namespaces, lots and lots of backslashes, and moving files around.
  • ORM has been completely rewritten.  I didn’t have much trouble with the old ORM, but I guess there are better ways of doing things.  Now, the Model is gone and it has been replaced with Table objects and Entities.  These are somewhat logical.  Table objects provide access to collections of records, while Entities provide access to individual records.  More or less.  It’s more flexible than that.
  • Immutable configurations for logs and caching.  Again, logical.  Instead of changing things on the fly, unload one configuration and load another one.
  • Named parameters in routing are gone now.  Apparently, it was a very complicated piece of code which caused a lot of headaches.  I somewhat enjoyed them in a few projects though, but can live without.  Not a biggy.  Furthermore, all of the routing has been reworked and will be much faster, using scoped routes, which I need to learn more about myself.
  • Asset.filter is gone now.  This should be handled via a plugin.  Have a look at Mark Story’s Asset Compress, for example.
  • Scaffolding is removed also.  That’s a pity, actually, as I used it for quick prototyping a lot.  There is a possibility of a standalone plugin to provide this functionality. There will be a much more powerful Crud plugin instead.
  • A few changes around encryption things.  It looks like anyone brave enough to migrate an application from CakePHP 2 to CakePHP 3 will also have to decrypt/encrypt some data as well.  Gladly, this is not my case currently.
  • FormHelper and HtmlHelper are now much flexible with the HTML that they produce.  These are great news indeed, as I’ve been a few times through pulling a CSS framework (like Twitter Bootstrap) over the CakePHP, and while it’s very possible, I had no fun at all.
  • I18n is possibly being pushed more towards better support of PHP’s intl extension. (It’s still a maybe, particularly due to intl extension not being installed universally.)
  • Tests are pushed more towards PHPUnit compliance.

Overall, that’s a monster of a change and it will take some reading and playing around to get used to the new ways.  The earlier, the better, I guess.