To whom it may concern:

My company was considering using livestream as a live streaming provider for our educational content.  This new initiative has convinced me to look elsewhere, as it has been my experience that anti-piracy measures only hurt consumers and small businesses.  It may be true that these measures protect very large (and outmoded) copyright holders, but at the same time they hamper innovation and limit consumer access to content.  We would rather partner with a company that devotes 100% of its resources to providing the best service possible.

Regards,

Chris Morrell

Sure, piracy is a real issue.  As a content producer I certainly understand the desire to stop people from stealing stuff I worked really hard to make.  But I think anti-piracy is a much bigger issue.  DRM and its cohorts have made it impossible for me to consume content I own a few too many times for me to support a company that has declared that it’s making anti-piracy a top concern.

I want to say thanks to everyone who came out to the event! Also thanks to Joe Kaufman and Rob Hall for their fantastic presentations. We ran a little long and some folks had to leave before seeing Joe’s demo, so I just wanted to mention it here. For those of you who haven’t see it, GameSalad is pretty magical, and the demo definitely got more than one round of applause. Check it out (take a minute or two to watch the demo video—you’ll be blown away). You should also check out Rob’s PhillyGeekCentral app (written entirely in ActionScript 3 and compiled using Flash CS5).

Beyond that I just wanted to open up the comments for any feedback anyone might have on my talk, and to answer any questions that came up after we finished with Q&A. Feedback is particularly useful to me (and don’t be afraid to criticize—I can handle it) because I haven’t done much presenting and am still trying to get a sense for what works and what doesn’t.

There are two things that came up in private after the presentation that I think are worth sharing with everyone:

1. A couple people asked me about styling applications written for PhoneGap or Titanium. In the case of PhoneGap you don’t really get any built-in styles because it’s really just a web page running in a chrome-less browser. That means if you want to mimic the iPhone’s UI or create something similar, you have to do it all with CSS and JavaScript. Luckily there are a number of frameworks out there that do that for you, and when I get my slides online I’ll have a bunch of resources to start with. For right now I would recommend checking out XUI and jQTouch. These tools help you get a nice mobile UI up and running in no time. (It’s worth mentioning that in the case of Titanium this is less of an issue because you can use native components.)
2. I also noticed that the question of local storage came up a few times, and I just wanted to clarify there. Mobile Web Apps, PhoneGap Apps and Titanium Apps all have access to local storage. Even in a web app, you can save settings to the phone that will still be there when the user closes Mobile Safari and reopens it. You don’t have to talk to a web server at all if you don’t want to.

Finally, I wanted to talk a little about choosing whether you should build a web app or a native app. This is something I’ve been thinking about a lot and just didn’t have time to talk about last night. Right now everyone is trying to get on Apple’s App Store. It seems like most major web sites either have native apps on the store already, or are planning to do so soon. But in the case of services that aren’t used daily (or at least weekly) I don’t think this makes any sense. There’s a reason that Kayak.com (thanks to Andy Mroczkowski for this perfect example) is a web site and not a program that you download for your computer; For services that you only use time-to-time, it doesn’t make any sense to use a dedicated application. So why would you want a dedicated application on your phone? Well, you probably don’t. But because everyone needs to be on the App Store today, that’s where you’ll find Kayak’s best mobile interactions.

That’s not to say that there aren’t a ton of instances where a native app wouldn’t be worth it. I just think that far too many people are trying to develop native apps when they really aught to be working on great mobile web sites (or web apps). Just like anything else, think about your users and their needs and choose the best option for them, even if it’s not 100% buzzword friendly.

Well, this post came out a lot longer than anticipated. If you can’t tell, mobile development is a topic that I’m happy to talk about, so if you have question feel free to ask.

Here are some of the resources I mentioned for mobile app development:

• Safari Mobile Web Programming
• Viewport Meta Element
• CSS3 Media Queries
• PhoneGap
• Titanium Mobile
• Apple iPhone Dev Center
• W3C Geolocation API
• Offline Storage & Caching
• CSS3 Transitions

About a month ago I posted some ideas about PHP modeling in the Zend Framework and requested feedback. After a month of on-and-off discussions through this website and #zftalk I decided to sit down and implement things a little more.

I now have some working base classes that can be found on GitHub. Right now I’m still thinking things out, so there’s no guarantee that’s the structure I’m going to finish with, but it’s what I’m playing with right now. So far I’ve dropped the DAO interface and the Galahad_Service parent class all together (since both are going to be pretty unique to your application). What’s left is mostly the Entity class and the DataMapper class (as well as a very generic Collection class).

I’ve also started to write some tooling for my modeling system, based on Zend_Tool. Right now it’s generating the model itself, a DAO based on Zend_Db_Table and a Zend_Form (see Matthew Weier O’Phinney’s post about using forms in your models for my reasoning there). It doesn’t generate the DataMapper yet, but that’s just a matter of writing the code…

Again, I’d love some feedback on the direction this is going. Check out the video below and then let me know. Comment below, email me at *****@cmorrell.com or get in touch on Twitter: @inxilpro.

[View full size, or watch below]

Follow-up Video (demo of a lot more code):

identity = base64(encrypt_rijndael256([
	sha512_hmac(username, appUsernameSecret),
	sha512_hmac(password, appPasswordSecret)
], appSecret))

This would produce an base64 representation of an encrypted array of hashes.  Basically, the system would produce two hashes using HMAC and two separate secret keys (one for the username hash and one for the password hash).  It would store that data in a way that it could later retrieve it (in my case a serialized array) and then encrypt the whole thing with a third key (the base64 is just so it could easily be represented by an ASCII string).  That way there are multiple points of failure.  An attacker would have to know all three keys just to get at the hashes, but then that’s all they’d have.  They’d still need to brute force both the username and password separately.  It seems to me that this would be pretty darn secure.  Clearly not good enough for a bank, but certainly fine for a web app that would have very few negative consequences if it were broken into.

I would love feedback from someone who know’s what they’re talking about   Below is some working PHP code to illustrate my point:

class PublicAuth
{
    private $_secret;
    private $_usernameSecret;
    private $_passwordSecret;

    private $_td = null;
    private $_iv = null;

    public function __construct($secret, $usernameSecret, $passwordSecret)
    {
        $this->_secret = $secret;
        $this->_usernameSecret = $usernameSecret;
        $this->_passwordSecret = $passwordSecret;
    }

    public function generateIdentifier($username, $password, $algorithm = 'sha512')
    {
        return $this->_encrypt(serialize(array(
            hash_hmac($algorithm, $username, $this->_usernameSecret, true),
            hash_hmac($algorithm, $password, $this->_passwordSecret, true),
        )));
    }

    public function verifyIdentity($identifier, $username, $password, $algorithm = 'sha512')
    {
        $identifier = unserialize($this->_decrypt($identifier));
        return (hash_hmac($algorithm, $username, $this->_usernameSecret, true) == $identifier[0]
            && hash_hmac($algorithm, $password, $this->_passwordSecret, true) == $identifier[1]);
    }

    private function _encrypt($string)
    {
        $this->_initMcrypt();
        return base64_encode(mcrypt_generic($this->_td, $string));
    }

    private function _decrypt($string)
    {
        $this->_initMcrypt();
        return mdecrypt_generic($this->_td, base64_decode($string));
    }

    private function _initMcrypt($algorithm = 'rijndael-256')
    {
        if (null == $this->_td || null == $this->_iv) {
            $this->_td = mcrypt_module_open($algorithm, '', 'ecb', '');
            $this->_iv = mcrypt_create_iv(mcrypt_enc_get_iv_size($this->_td), MCRYPT_RAND);
        }

        mcrypt_generic_init($this->_td, $this->_secret, $this->_iv);
    }
}

And here’s some sample usage:

$pa = new PublicAuth('a', 'b', 'c');
echo $pa->generateIdentifier('user', 'pass');

Which would print out:

NLgAYjlGbmJA2Wdcgwntm4ixhHHCiZBA6TvgrVMgEOBEjZQJ0tHgAlw7931p2S6KRtfCkLjrsA2DBilcgBX/pPPXFgyAx3g0/CKMcjdU8DKn3/9M2aIZHOrdi/G68C0oxVe6pDlWvVwvofpJnu9RxMbFN49x1uVgBuHTjKagpD6y83fm+hX4G+CoPRcHM5PUq/nJ1iwtZipRtno8TllO6A==

Then to verify the identity:

$pa = new PublicAuth('a', 'b', 'c'); // Needs to be the same as when generated
var_export($pa->verifyIdentity($id, 'user', 'pass')); // $id contains the string above; returns TRUE

Thoughts?

$jan1 = new Zend_Date('1.12.2009', Zend_Date::DATES);
echo "\nJanuary first: ", $jan1->toString();

$christmas = new Zend_Date('25.12.2009', Zend_Date::DATES);
echo "\nChristmas is on: ", $christmas->toString();

$diff = $christmas->sub($jan1);
echo "\nNumber of days: ", $diff / 60 / 60 / 24;

Zend Framework’s project lead, Matthew Weier O’Phinney, has a lot of great thoughts about Modeling that I’ve been trying to stick to. In implementing those ideas, I’ve started thinking out some base classes to build my Models on top of. Obviously these classes won’t work for everyone. But they should work for a lot of “typical” web applications.

That said, here are some notes that I’ve been putting together. I’m posting them now (very early) in hopes that I get some feedback.

The 6 Classes

Galahad_Model

This is the base class that all my others extend. It is there mostly to provide some helper functionality that all my other classes use (mostly for guessing class names based on a naming convention—more on that later).

Galahad_Model_Entity

The Entity is the base for all things. For example, a User would extend the Entity class. The Galahad_Model_Entity class has some basic methods for getting other objects. I haven’t thought this entirely through yet, but an example would be the Entity’s “Parent” Service (see below) or maybe a Form associated with that model or something similar.

Galahad_Model_Collection

The Collection class is just a wrapper for an array of Entities. I like this because it allows for type hinting/etc. This is pretty much a generic wrapper for an array that implements Iterator and Countable. I can’t think of much more that it needs.

Galahad_Model_Service

This probably doesn’t belong as part of the “Model”—I need to think that out. The Service Layer is where your application logic happens that’s not strictly part of a particular Model (for example, an interaction between two Models). An example might be authentication. The service layer will often map pretty closely to a public API (although obviously there will be things that your application can do that shouldn’t be exposed to the public).

Galahad_Model_DataMapper

The DataMapper maps your Entity to the appropriate DAO (see below) and makes sure the DAO gets the data it’s expecting. The way I think about this is that the Data Mapper expects an Entity as its input, but passes an array to the DAO.

Galahad_Model_Dao

The Data Access Object (DAO) is what takes the actual data in your entity and persists it. The most common DAO is going to be a database, but a web service could be a DAO as could a filesystem or any other method of persisting data. The DAO is going to have similar methods as the DataMapper, but it expects just the data—nothing else (that’s why you need the DataMapper to fetch and process the data in your Entity). An easy way to show this is in code:

class Default_Model_DataMapper_User
  extends Galahad_Model_DataMapper
{
    public function save(User $user)
    {
        $dao = $this->_getDao();
        $dao->save(array(
            'name' => $user->getName(),
            'email' => $user->getEmail(),
            'date_modified' => time(),
        ));
    }
}
class Default_Model_Dao_DbTable_User
  extends Zend_Db_Table_Abstract
  implements Galahad_Model_Dao_Interface
{
    protected $_name = 'user';

    public function save(Array $data)
    {
        $this->insert($data);
    }
}

Notes

I’m going to reiterate one more time that this is a very early concept and that I’m looking for feedback. It could be that I’m thinking about things completely backwards and it all needs to be thrown away. At this point I certainly don’t recommend people running too far with these ideas until they’ve been discussed/thought out a little more.

About the Galahad_Model base class—since all the different pieces of your model will likely follow the same naming conventions, the Galahad_Model class provides some helper functionality to guess the name of classes. For example, inside of Default_Model_DataMapper_User you’ll probably need to get an instance of Default_Model_Dao_DbTable_User. So Galahad_Model_DataMapper provides a nice getDao() method to do this for you. If you’ve set the DAO, it uses that, but if you didn’t, it assumes you want a DbTable, guesses the name for you based on the DataMapper’s class name (so that if you choose My_Model_DataMapper_Person it’ll know to return a My_Model_Dao_DbTable_Person) and instantiates it for you.

Thoughts?

What do you think? Does this make any sense? Or am I trying to make a simple thing more complicated than it needs to be? I think a lot of this would make more sense in code, so maybe I’ll try to get what I have started cleaned up a little and attach it to this post. In the meantime, I’d love feedback (in the comments below, or to @inxilpro.

Well, that’s exactly what my Flickr/Tweetie Bridge does.  Just set it up, plug the URL into Tweetie, and you can start uploading/shortening with Flickr.  It hasn’t been very heavily tested, but it’s working fine for me.  Check out the 0.1 release.  It’s PHP5-only, and released under GPL.

Let me know if you come across any bugs, or have feature requests.

<link rev="canonical" rel="self alternate shorter shorturl shortlink" href="..." />

I haven’t yet implemented my own short URLs, but when I do I think that the way I’ll go.

First, download the Plugin

Put the following class in a library/Galahad/Controller/Plugin/Modularlayout.php file (you’ll probably have to create all those directories and the file).

<?php
/**
* This file is part of the Galahad Framework Extension.
*
* The Galahad Framework Extension is free software: you can redistribute
* it and/or modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation, either version 3 of the
* License, or (at your option) any later version.
*
* The Galahad Framework Extension is distributed in the hope that it will
* be useful, but WITHOUT ANY WARRANTY; without even the implied warranty
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
* General Public License for more details.
*
* @category  Galahad
* @package   Galahad
* @copyright Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license   GPL <http://www.gnu.org/licenses/>
* @version   0.2
*/

/**
* Use separate layout per module
*
* @category   Galahad
* @package    Galahad
* @copyright  Copyright (c) 2009 Chris Morrell <http://cmorrell.com>
* @license    GPL <http://www.gnu.org/licenses/>
*/
class Galahad_Controller_Plugin_Modularlayout extends Zend_Controller_Plugin_Abstract
{
     public function routeShutdown(Zend_Controller_Request_Abstract $request)
     {
          Zend_Layout::getMvcInstance()->setLayout($request->getModuleName());
     }
}

Next, add the Galahad namespace

Update your Bootstrap.php file’s autoloader initialization method (if you don’t have one, add one):

protected function _initAutoloaders()
{
	$this->getApplication()->setAutoloaderNamespaces(array('Galahad_'));
	return $this;
}

Please note: You might need to have other namespaces in there, like My_ or App_ or Default_.

Next, add the Plugin

Update your Bootstrap.php file’s plugin initialization method (if you don’t have one, add one):

protected function _initPlugins()
{
	$this->bootstrap('autoloaders');
	$this->bootstrap('frontController');

	$plugin = new Galahad_Controller_Plugin_Modularlayout();
        $this->frontController->registerPlugin($plugin);
}

And you’re set!

Just make sure you have a layout file in your layouts directory for each module (modulename.phtml).