With Accelerated Mobile Pages (AMP) being all the rage recently, I found “How fast is AMP really?” article interesting. It looks like it’s worth spending a tiny bit of time adding AMP to your site, especially if it was developed with one of the common and widely used tools, like WordPress. And if mobile page performance is important for your project, than there’s even more that you can benefit from.
Month: April 2018
Color: From Hexcodes to Eyeballs
“Color: From Hexcodes to Eyeballs” is one of the best articles on color theory and the relationship between color coding, hardware, and human color perception, that I’ve seen in a long while. Scratch that. That I’ve seen EVER!
I was already somewhat familiar with the subject, so I scrolled through the article twice, quick read it, and will have to spend even more time with it. But if you want to really understand how this part of technology works with humans, it’s the best resource that I can send you to.
What Is gtag.js with Google Analytics and Do I Need It?
If you are using Google Analytics, or any other Google marketing tool on your website, make sure to read through the “What is gtag.js with Google Analytics and do I need it?” article. It explains the change in the Google Analytics tracking scripts which are slowly rolling out, and provides some insight into the future.
Why SQLite Does Not Use Git
Git is a pretty much standard de facto for version control when it comes to the modern software development. Yet, there are still many projects, companies, and developers who don’t use it. Some, like WordPress, for historical reasons – it’ll take a lot of work to migrate all of the infrastructure and community to git. Others, for personal preference. An example of the latter is SQLite.
Here’s an interesting article on why SQLite does not use git. The core reason is simple – the main developer of the SQLite just doesn’t like git, and there is nothing wrong with it. But in the article there are a few specific technical reasons of why not git, and why Fossil.
CakePHP 3.6.0 release
My all time favorite PHP framework – CakePHP has recently announced the availability of the long awaited version 3.6.0. What’s so special about this particular version? – those of you not very familiar with CakePHP might ask. And I’ll tell you.
CakePHP is a well established framework, with long history – going strong for 13 years now (initial release was in April of 2005). In web development, 13 years is a very long time. Old tools fade away. New versions of the language and popular libraries come into play. And it’s the job of the framework to change and adjust smoothly, providing the developer with the best and greatest, without breaking applications. That’s not an easy task – ask anybody who had to maintain any codebase for longer than a couple of years.
I started using CakePHP back in 2007-2008 or so. It was version 1.x and it was great. At the time. Then, a few years later, version 2.x was released, and as a major releases often do, it broke backward compatibility. The most painful change at the time was still easy to fix – it was the change in the naming convention for folders, files, and classes. CakePHP 2.x switched from their own naming convention to the PSR-2 Coding Style.
About 4 years ago, CakePHP 3.x was released, and this time it was the major of the major releases. CakePHP framework got a lot better (and I do mean A LOT), but the price was an impossible migration. One of the big changes in that version was the complete rewrite of the model layer and the ORM, which meant moving the CakePHP application from version 2.x to 3.x meant an almost complete rewrite (as most applications have most of the code in the model layer anyway).
That was a huge pain and community reacted. Everybody wanted to use the cool new features of CakePHP 3, but nobody could afford to rewrite almost all of the application for this version of the framework. (By the way, this situation is not unique to CakePHP – pretty much all other frameworks, both in PHP and other languages, either faced it or will face it in the future – that’s just how things are done).
When the CakePHP 4 roadmap was announced, one of the first things that CakePHP core developers team addressed was the upgrade path. From the start they said that there must be a better way to handle major upgrades of the framework, and that they will find it. And they did!
This time around, there was some ground work laid out. Instead of just dropping another major release into developers’ laps and all the upgrade pain that comes with it, CakePHP developers absorbed a lot of it on their end, and softened the transition. How did they do it?
Well, that’s where we get to the exciting CakePHP 3.6.0 release! You see, the plan was do provide the gradual transition and give developers warnings and time to adjust their applications. From the early stages of the CakePHP 3.x, a lot of functionality was commented as deprecated. Any developer building with CakePHP framework could easily find what’s gonna go in the next major release. But developers are always busy and never have the time for looking up things. So what CakePHP 3.6.0 does is quite elegant. It introduces deprecated warnings for all the functionality that will be removed in CakePHP 4. This means that once you upgrade to CakePHP 3.6.0 your logs will get a lot noisier, telling you exactly what needs fixing. If you don’t have the time right now, or want to ignore these warnings for now, you can simply disable them by adjusting the error reporting configuration, and all works as before. But if you want to get ready for the next major version of CakePHP, then you have precise information of what needs to be fixed in your application. Fixing one issue at a time, when you have the time, is great!
In fact, at work, we loved this approach so much that we started using it for our own projects as well. Switching between different projects across several developers, and working on some old projects, etc., makes things difficult to remember. With deprecated warnings, things are a lot simpler.
So, ladies and gentlemen, if you were looking for a framework to try, give CakePHP 3.6.0 a go. You’ll easily upgrade to CakePHP 4 when it becomes available. And if you were already using CakePHP 3, upgrade to CakePHP 3.6.0 and check your logs for deprecated warnings.
And, of course, stay tuned for CakePHP 4!