Memcache(d) Archives - developed.be

Laravel works out of the box with Memcached. However there’s a difference between the linux programs Memcached and Memcache (without the D). To get Laravel to work with Memcache you can write a package yourself.

First of all: don’t edit the original files of the Laravel package. I know you can just find/replace every instance of Memcached and replace it by Memcache, but as soon as you’ll update your project, every change you’ve made to the core files will be overridden and lost. That’s why you have to create a separate package that adds functionality to the system instead of blindly editing the system.

Continue reading “Laravel use Memcache instead of MemcacheD”…

It felt like a Monday morning. After my alarm clock didn’t get off (+ 1 hour), I noticed there was only a train 1 hour later, so instead of arriving at half past 9, I arrived at 11 and missed the first speaker.

Lightswith + Drupal

Anyhow. I picked up the last quarter of using Drupal together with Lightswitch (= Visual Studio). Apparently not a lot of devs had interest in the subject because there were only 20 people in the room. And those who didn’t attend were right, because all the speaker could tell us was that marrying Drupal and Lightswith could only result in a divorce.

Lightswitch can create a HTML5-admin environment based on a data layer. That data layer could be your Drupal database. Nothing works out the box for Drupal because MS of course wants to integrate their software (SharePoint, Office) and not someone else’s software.

Another downsides of all these MS-Drag-And-Drop-Automatic-Data-Layer-Builder-stuff, is that when you change your database, something on the other side might break and you could end up writing the data layer yourself (as a attendee commented). Plus, the actual html output looks weak and is unusable in a serious professional environment. Don’t try this at work, pro’s!

Drupal 8 discussion panel

Three Belgian core-devs (swentel, Wim Leers, aspilicious) had a one hour Q&A hour about Drupal 8. They all had a lot to tell so the number of actual public questions was limited.

You had to know some Drupal 8 in forehand, because new projects (say WSCCI, PSR or TWIG) were discussed without being explained.

The main message was that Drupal 8 is ready to port your modules to. But, there’s still a lot of work to be done. There are still upcoming API-changes, you can’t translate a node’s title yet and there are various other big and small release blockers. But: Views should be finished. Ah!

And why Drupal 8 should be better that its processors:

  • PSR proof. PSR is a PHP coding standard. (aimed for PSR 4 however, it’s uncertain if it the project will get there)
  • Display Suite is now a core module (however, is this really such a big plus?)
  • Getting rid of the hooks in favor for a more object oriented way (however, hooks still exist)

Continue reading “DrupalCamp Leuven 2013, a brief Saturday review.”…