Twitter and identi.ca are fine for what they are: immediate distribution of small pieces of information that are connected primarily by a timeframe and a shared experience. However, they are unsuitable for extended, nuanced dialogue on any topic requiring thoughtful consideration. Commentary in such locations disappears too quickly into the ether. I said back in May 2009 that Twitter is too “constrained and ephemeral” and I stand by that assessment. You want to create something that lasts (as much as anything lasts in a digital ecology)? Blog it.
This is a topic I describe at length in my Organizing talk, but I would like to give the idea a home on my blog for easy reference.
Typical PHP uses what I call an include-based architecture. By this, I mean that the mere fact of including or requiring a file causes the execution of program code or business logic.
<?php include 'config.php'; include 'header.php'; // ... // do some work, probably including other files // ... include 'footer.php';
The application is composed of files that the user browses to directly. Those included files may include other files for additional business logic. This is the basic structure of most PHP applications.
At some point, the PHP programmer starts writing his own functions to encasulate repeated behaviors, and starts including a file of those functions. As a follow-on, the programmer may begin to adopt object-oriented programming and start to collect his functions into classes along with related data structures.
The functions and classes do not end up changing the basic structure of the include-based application. The programmer still has a series of pages that users will browse to directly. Those pages load up classes and functions and use them as helpers to perform business logic that is mostly still in the page script.
By contrast, a class-based architecture is what we generally see in the MVC frameworks of the past 10 years or so. The user browses to a bootstrap script (the only “page” in the whole system). That script then reads the request and picks out a business-logic class to instantiate, and calls a method on that object instance to make it run. From that point on, all behaviors are contained in class methods, not in page scripts. This is what I mean by a class-based architecture; that is, all of the main program logic is embedded in classes, not in page scripts.
In talking about the distinction between include-based and class-based architectures, one programmer I know said, “There’s no real difference between include-based and class-based. You still need to include the class file, after all.” Yes, you do need to load the class file. The difference is that no program logic is executed at loading time with a class file. Loading the class file makes it available for use, but the programmer has to instantiate it and then call methods on it for anything else to happen. With include-based architectures, merely loading the file will execute program logic.
OpenID has never really caught on in a major way. I use it pretty much only on StackOverflow and 37signals products, and I really like it. Regular (non-web-building) users find it puzzling, and don’t have a good understanding of URLs, let alone ownership of them. So it works for geeks, but not for the general populous, and therefore isn’t a good viable solution for most sites.
via OpenID Has Failed. So What’s Next? — All in the head. The quote is from a conversation with David Sklar.
I am the first one to admit that I am not a UI/UX/design person. I believe wholeheartedly that the inmates are running the asylum when they shouldn’t be.
The project page at http://auraphp.github.com/ has substance, but no style, and style is so important. Can anyone recommend a good design guy who is interested in working his craft on an open-source project, where the only payment will be appreciation and good-will?
(Incidentally, that person is likely to end up being the lead advisor for anything related to style in the Aura libraries.)
Leave a comment, or email me directly, if you have a lead. Thanks!
Cal Evans has posted his interview with yours truly: Interview with Paul M. Jones | Voices of the ElePHPant. Thanks for inviting me, Cal!
Measuring from the first Subversion commit, Solar was 6 years old on 14 Feb 2011. The project has come a long way since then, and has evolved from a collection of library classes with some content domain models, to a general purpose framework.
Moore’s Law tells us computer power doubles about every 18 months; it’s how we measure generations for computers. 6 years is 4 generations, which makes Solar the equivalent of an 80 to 100 year old person. Just like with a mature person, there is a great deal of knowledge and craft embedded in Solar, but it also still shows its roots and carries the weight of decisions from early in its life.
With all that in mind, it’s time to start working on Solar version two, using the formal namespaces and other features of PHP 5.3. There are some other very significant changes on the way as well.
The first change is the name of the project. Even though Solar (the PHP 5 framework) came first, the name is too easy to confuse with Apache Solr (the search system). So, after some discussion with others, Solar v2 will be called Aura.
The second change is in the fundamental organization of the project. Solar became a full-stack framework very quickly, with all classes descending from a base class, and using and a service locator to manage dependencies. By comparison, Aura is a collection of independent library packages; it uses no base classes, and is oriented toward a dependency injection container proper to manage dependencies. Aura also has an additional “system” package that assembles those libraries into a cohesive framework (the way Solar is now). That way, those who want to use only one or two Aura packages can do so, and developers who want a full framework can also get what they need.
There are lots of other significant changes, and I expect I’ll write about those in the future. Until then, if the project sounds interesting, you can find the Github repos at https://github.com/auraphp. Aura also has a mailing list at https://groups.google.com/group/auraphp, and you can join the IRC room on Freenode at
Meanwhile, Solar will keep getting as much love and attention as it has over the past year or so. But I do expect, eventually, that we will be able to extract all the best Solar behaviors to Aura. Solar won’t ever really go away (software projects almost never do), but I expect it will be eclipsed by Aura at some point in the future.
You can see what Aura looks like by examining the various Aura packages already in place:
- Aura.Autoload, an autoloader package
- Aura.Di, a dependency injection container,
- Aura.Router, a web routing system,
- Aura.Signal, a signal slots / event handler implementation,
- Aura.Cli, a collection of command-line tools, and
- the system package that provides a framework around the libraries
Take a look around; I hope PHP 5.3+ developers who want independent library packages will like what they see.