PapayaSoft - Phuket web development

You’ve Ruined Me. All of You.

| Comments

(A message to my colleagues and the broader dev community, in general)

Look at what you people have done to me in two short years.

So, I do a little work on a branch. Change a few files:

1
2
3
4
5
6
7
8
9
10
11
12
13
davidweinraub@copernicus:~/apps/myproject [mybranch*]$ git st
On branch mybranch
Your branch is up-to-date with 'origin/mybranch'

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   app/src/SomeProject/Controller/SomeSubspace/Featured.php
    modified:   app/src/SomeProject/Controller/SomeSubspace/Shows.php
    modified:   app/src/SomeProject/Model/SomeSubspace/Featured.php

no changes added to commit (use "git add" and/or "git commit -a")

Turns out that I only want to commit the two Featured files. So rather than mouse/trackpad, select, copy, paste, I do the following:

1
davidweinraub@copernicus:~/apps/myproject [mybranch*]$ find ./app/src/ -name "*Featured*.php" | xargs git add

which, of course, results in:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
davidweinraub@copernicus:~/apps/myproject [mybranch*]$ git st
On branch mybranch
Your branch is up-to-date with 'origin/mybranch'

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   app/src/SomeProject/Controller/SomeSubspace/Featured.php
    modified:   app/src/SomeProject/Model/SomeSubspace/Featured.php

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   app/src/SomeProject/Controller/SomeSubspace/Shows.php

You’ve ruined me. All of you.

And seriously, I can’t thank you enough. Seriously. :D

Custom Chmod Permissions During Octopress Deploy via Rsync

| Comments

So, today my blog/site started throwing 500 errors on every page. Actually, it might have been doing it for a while; I’ve been crazy busy lately, so haven’t checked. Need to get some automatic monitoring set up. But I only noticed it today.

A quick check of the error log shows that there was some file permission issue. My host requires that directories have permission 755 and files have permission 644. Somehow the deployed files were not getting that.

As noted in a prior post, I am using Octopress and deploying using the rsync functionality inside Octopress’s rake deploy. Clearly, rsync was not being informed of the directory/file permission requirements.

A quick search gave me the required permission syntax for rsync:

1
--chmod=Du=rwx,Dg=rx,Do=rx,Fu=rw,Fg=r,Fo=r

[As a side note: Look at how beautiful that syntax is. It clearly exposes the granularity of the three user groups, the three permission levels, and the different handling between directories and files. Commandline rocks! :D ]

Even better, Octopress is smart enough to provide a place in the Rakefile to add these params:

1
rsync_args     = "--chmod=Du=rwx,Dg=rx,Do=rx,Fu=rw,Fg=r,Fo=r"

Added this, ran a rake deploy and all cool.

Review - ‘Twilio Cookbook’ by Roger Stringer From Packt

| Comments

Twilio Cookbook is a useful introduction, accessible to PHP developers at all levels, to developing apps using Twilio’s telephony platform. I had no experience with Twilio before reading this book and I now feel confident that I could easily incorporate Twilio functionality into my own applications.

The book is part of Packt’s “Cookbook” series, so it contains a fairly structured format for each application/recipe. The format can be roughly summarized in three steps:

  • What we are going to do: a brief overview of the app/goal
  • How to do it: the code, the recipe itself
  • How it works: a more detailed explanation of what the code achieves

The book clearly demonstrates how Twilio can be used to implement a wide variety of web-controlled telephony services, including SMS-based or Voice-based two-factor authentication, SMS-based surveys, conference calling, voice-mail with notifications, and others.

In general, the recipes often boil down to:

  1. put a script (or collection of scripts) on your publicly accessible web-server, and
  2. point your Twilio phone number to that script.

Like other reviewers, I would have liked to see more conceptual overview of Twilio’s services. But the Cookbook format is geared towards diving right in to code and building bare-bones functional prototypes. You won’t find a lot of advanced web best-practices here – there is no MVC or separation of concerns; there is very little error-checking or escaping of user input; the HTML is unstyled, bare-bones links and forms; there are variables in global scopex; etc. As such, the recipes are not really suitable for production use.

But for the purposes of the book – demonstrating the core functionality of the Twilio system – stripping out all those considerations is actually beneficial, resulting in a clear exposition without any of those potentially distracting (though definitely necessary) aspects of general app-development.

In summary, Twilio Cookbook successfully does what it sets out to do. It demonstrates how to implement a wide range of telephony functionality using PHP and Twilio.

The book is available on both Amazon and on Packt.

Composer Process Timeout When Fetching Large Repositories

| Comments

Yesterday I was doing a composer install from within my VM, but it kept timing out.

My first assumption was some network problem since my internet service is relatively slow and unreliable (at least compared to more developed places), especially from within my VM. But numerous tests suggested that my internet connectivity was ok.

Invoking Composer with the -vv verbose option showed me that it was failing while attemtping to clone the symfony/filesystem repo from GitHub. Cloning this repo directly, outside of the context of a composer install/update, succeeded. But it was a large repo and took a while.

All this suggested that Composer itself was imposing a limit on how long it would allow for the remote git operation. A look at the Composer documentation confirmed that the environment variable COMPOSER_PROCESS_TIMEOUT governs this. The variable is set to a default value of 300 (seconds) which was apparently not enough for a large clone operation using my slow internet connection. Raising this value using:

1
COMPOSER_PROCESS_TIMEOUT=2000 php composer.phar install

got me over the hump.

Many thanks for NileWebSites for their post that made me aware of this.

Debugging a Web-app in a Vagrant-provisioned VirtualBox VM Using Netbeans

| Comments

Our team has begun to use Vagrant to provision controlled virtual machine environments for all our development. It’s a cool concept, but I was left without the ability to use my Netbeans debugger. It took a little fiddling around to get it right, but I didn’t think about blogging about it until:

  1. Jake McGraw wisely suggested it on Twitter.
  2. I realized that I had re-provisioned my virtual machine (VM) and was maddeningly unable to reproduce what I had done.

So, as much as I hope this will be a help to others, getting it down someplace is as much an act of self-interest as it is altruism.

Accessing Zend Framework Application Resources and Config Options in Module Bootstraps

| Comments

A quick post to document something I tripped over today. As usual, mostly for my own benefit since there is a decent chance that I’ll completely forget it the next time I need it.

I had a Zend Framework 1.11 app using Zend_Application and its bootstrap process. The application had several modules. So, in application/configs/application.ini:

resources.modules.front = "front"
resources.modules.auth  = "auth"
resources.modules.admin = "admin"

And each module bootstrap class extended Zend_Application_Module_Bootstrap. For example, the bootstrap class for the module named “front” looked like:

class Front_Bootstrap extends Zend_Application_Module_Bootstrap
{
    protected function _initSomething()
    {
        // init something
    }
}

And there were some app-level application resources – like cachemanager, for example – that were defined in the usual way:

resources.cachemanager.feed.frontend.name = Core
resources.cachemanager.feed.frontend.options.lifetime = 21600
resources.cachemanager.feed.frontend.options.automatic_serialization = true
resources.cachemanager.feed.backend.name = File
resources.cachemanager.feed.backend.options.cache_dir = APPLICATION_PATH "/../data/cache"

All straightforward and working fine, as it has on many previous occasions.

In my module bootstraps, I was registering some front-controller plugins that needed to access those bootstrapped application resources and config data (the cachemanager resource and a feed url, respectively) that were all specified at app-level. So, I tried to access them in the module-level bootstrap using:

class Front_Bootstrap extends Zend_Application_Module_Bootstrap
{
    protected function _initSomething()
    {
        // get some options, used later
        $options = $this->getOptions();

        // use built-in dependency tracking
        $this->bootstrap('cachemanager');

        // get the bootstrapped resource
        $cachemanager = $this->getResource('cachemanager');

        // do more, with the options and the cachemanager
    }
}

Result: The variable $options was merely an empty array and the app would die when trying to access the cachemanager resource.

Apparently since we configured/instantiated all these at the app-level (!), I need to access them through the app-level (!) bootstrap which I can get using $this->getApplication(). So the correct code is:

class Front_Bootstrap extends Zend_Application_Module_Bootstrap
{
    protected function _initSomething()
    {
         // get the application-level bootstrap first
         $application = $this->getApplication();

        // get some options, used later
        $options = $application->getOptions();

        // use built-in dependency management
        $application->bootstrap('cachemanager');

        // get the bootstrapped resource
        $cachemanager = $application->getResource('cachemanager');

        // do more, with the options and the cachemanager
    }
}

In hindsight, and with all the explicit references I have made to the adjective ‘app-level”, it’s all pretty obvious. I will note that getApplication() does not return the Zend_Application instance (as the name kind-of implies), but rather the app-level bootstrap. As potentially misleading as the method name may be, I suppose it makes sense since the app-level bootstrap instance is usually more directly useful than the application instance.

With any luck, I’ll remember it next time. Until then, hope this helps someone else.

Zend Framework 2: Concepts, Flexibility, Complexity

| Comments

As I try to get my own head around the ongoing development of Zend Framework 2 (ZF2) and as I see other beginner/intermediate developers ask similar questions, I thought it would be useful – to me at least – to articulate some thoughts about how I understand ZF2 and some general concepts that could be helpful to understanding the framework. Hopefully, they will be helpful for newbies (and a few not-so-newbies) as well.

tl;dr: There is a lot of complexity in ZF2 that enables maximum flexibiltiy. I suspect that at some point in the future, much of this complexity can be wrapped in an easy-consumption layer that masks it for those common use-cases that do not require that flexibility.

Custom Frontends for Zend_Cache

| Comments

As we all know, server-side caching is a useful technique for optimizing the performance of web apps. Whenever some expensive operation is called for – a db query, a remote web service call, etc – caching the results of the operation means that the next time you need them, you can get them relatively cheaply from the cache.

Zend_Cache: A basic usage example

Zend Framework contains a Zend_Cache component that supports a variety of frontends and backends. Typical usage for filesystem-based caching is something like the following:

// create the cache object
$frontend = array(
    'lifetime' => 86400, // seconds
    'automatic_serialization' => true,
);
$backend = array(
    'cache_dir' => '/path/to/your/cache',
);
$cache = Zend_Cache::factory('Core', 'File', $frontend, $backend);

// now use the cache object
$cacheId = 'someCacheId';
$data = $cache->load($cacheId);
if (false == $data){
    $data = someExpensiveOperation();
    $cache->save($data, $cacheId);
}

In practice, I tend to put the cache creation portion into a factory/container class of some kind, while the usage/consumption is often in a repository or service class. But for clarity, it is shown all in line, as if it were in a controller.

The first time you run through this code, the data will not have been saved in cache (a cache miss, as they say), so you will be forced to incur the cost of the someExpensiveOperation() call. But the next time you run through it – assuming the cache has not expired beyond its lifetime – then you will register a cache hit and bypass the expensive operation.

All cool.

Yeah, but…

But there is one thing that has always bugged me about this typical flow: generating the $cacheId. For example, if someExpensiveOperation() is a db call to fetch an article, then the $cacheId will probably employ the id or slug of the article:

// $slug is the slug of the article, something like 'my-cool-article'
$cacheId = 'article_byslug_' . str_replace('-', '_', $slug);  // Zend_Cache does not like cache id's with hyphens

Generating a cache id strikes me as part of the internal details of the “caching process”. As such, it seems to me like the knowledge of how to do that should be embedded inside the caching object itself. It’s his business to know how to load data from cache, save data to cache, and remove data from cache. Connecting an id to that data should be part of his job. So, why should I have to construct cache id’s for him?

Even further, why am I seeing cache id’s at all? Couldn’t the cache object simply offer me an interface with methods like:

public function loadArticlebySlug($slug);
public function saveArticle($article);
public function removeArticleBySlug($slug);

Isn’t there some easy way to make this happen?

Custom cache frontends to the rescue!

It turns out that Zend_Cache::factory() actually does allow me to create custom frontends that implement whatever interface I want. I can define my interface:

interface Project_Cache_Frontend_ArticleInterface
{
    public function loadArticlebySlug($slug);
    public function saveArticle($article);
    public function removeArticleBySlug($slug);
}

Then implement in a class extending Zend_Cache_Core:

class Project_Cache_Frontend_Article extends Zend_Cache_Core implements Project_Cache_Frontend_ArticleInterface
{
    public function loadArticleBySlug($slug)
    {
        return $this->load($this->getCacheIdBySlug($slug));
    }
    
    public function saveArticle($article)
    {
        return $this->save($article, $this->getCacheIdBySlug($article->slug));
    }
    
    public function removeArticleBySlug($slug)
    {
        return $this->remove($this->getCacheIdBySlug($slug));
    }
    
    protected function getCacheIdBySlug($slug)
    {
        return 'article_byslug_' . str_replace('-', '_', $slug);
    }
}

Note the protected method getCacheIdBySlug($slug). All the knowledge of how to create cache id’s is wrapped up in the cache object. It just exposes a functional interface that describes what you want to do, not how you want it done.

Now, tell the Zend_Cache::factory() method to use my custom frontend:

// frontend and backend options as before
$frontend = array(
    'lifetime' => 86400, // seconds
    'automatic_serialization' => true,
);
$backend = array(
    'cache_dir' => '/path/to/your/cache',
);
$cache = Zend_Cache::factory('Project_Cache_Frontend_Article', 'File', $frontend, $backend, true, false, true);

Note that we are specifying the complete name of our implementing cache class, as well as three boolean values.

The first boolean value – true in this case – tells the factory that we are using a custom frontend.

The second boolean value – false in this case – tells the factory that we are not using a custom backend.

The third boolean value – true in this case – tells the factory to use autoloading to instantiate the frontend and backend objects.

Fully constructed by the factory with the custom frontend, cache usage is cleaner:

$article = $cache->loadArticleBySlug($slug);
if (false === $article){
    $article = someExpensiveOperationToGetArticleBySlug($slug);
    $cache->saveArticle($article);
}

No cache id’s, no mixing of concerns.

Maybe it’s a whole lot of work just to tuck away some cache id generation. But I confess that it feels better to me.

The PHP Community. My Community.

| Comments

I am a PHP developer. I use PHP for nearly all my server-side development. Much of my learning of design patterns and general best practices and has taken place within a PHP context.

I’ve been doing web development with PHP for a lot of years. During the past three years, I have plunged into new tools and methodologies – frameworks, MVC, source-control, modeling, layered app architecture, dependency-injection, unit-testing, automated build/deploy, schema migration, API design. It has been – and continues to be – a huge climb. I often feel like a n00b, the new kid in school who just moved from a foreign land and doesn’t even speak the language, braced to get teased in the playground during recess by the Cool Kids.

But you know what? The Cool Kids – the more experienced PHP developers – turned out to be, well, cool.

Whether it’s an independent developer based on the other side of the world starting his own project on Github, or the founder of a US-based local PHP user group, or an advisory member to several developer conferences, or even the project leads of various popular open-source projects, they have all been uniformly supportive of what I do know and amazingly tolerant of what I don’t know. These near-total strangers have invited me to local meetups, encouraged me to start my own user-groups and local meetups, have patiently and generously contributed their time to answering my – often naive – questions and pointing me to relevant resources.

The expertise that they have shared with me has proven invaluable in improving my skills. Even more notable is their warm humanity, their sharp-witted good humor, and their almost universal encouragement that moves me to ever deeper community engagement.

Upshot: This virtual community, this real community, the PHP community, rocks. It just flat out rocks.

The PHP community. My community.