Introducing Bullet: The Functional PHP Micro-Framework

Bullet is a new PHP micro-framework with a unique functional approach to URL routing that allows for more flexibility and requires less verbosity than the more typical full route+callback approach found in other micro-frameworks.

The Problem with Independent Scope

The main problem with most micro-frameworks and even full-stack MVC frameworks that leads to code duplication is that the callback or method executed to perform the action and respond to the URL route lives fully within its own scope. This means that you are forced to repeat a lot of setup code across URL route handlers that load the same resource, authorize it, etc.

Some typical micro-framework code might look like this:

<?php
// View single post
$app->get('/posts/:id', function($id) {
     $post = Post::find($id);
     check_user_acl_for($post);
     // ...
});

// Delete post
$app->delete('/posts/:id', function($id) {
     $post = Post::find($id);
     check_user_acl_for($post);
     $post->delete();
     // ...
});

// Edit post
$app->get('/posts/:id/edit', function($id) {
     $post = Post::find($id);
     check_user_acl_for($post);
     // ...
});

You may be able to move the ACL check to a middleware layer or “before” hook if the framework supports it, but there is always a certain amount of duplicate code you will either never be able to get rid of, or have to jump through hoops to get rid of (like adding more abstraction or re-checking the current URL, etc).

The Benefits of Shared Scope

Bullet uses a unique nested callback style that splits the URL by directory separator and only handles a single part of the URL at a time with it’s own callback. At first blush, this approach might seem like more work, but the key to how Bullet works is that nested closures – by definition – can use variables defined in the scope of their parent. This leads to some pretty powerful and profund capabilities that can only be done using the same nested closure style that Bullet uses.

Continue reading

Android+iPhone SEO App

I just released a new iPhone SEO app and Android SEO app called SEMTab SEO Pro. The basic idea is to keep a list of domains saved, and check SEO/SEM stats like Google PageRank (PR), backlinks, Alexa rank, etc. and Social share information from Twitter, Facebook, and Delicious. more

ss1-listss2-webss3-social1

 

The first two pictures are of the iPhone app, and the last one is of the Android app. SEMTab SEO Pro was built with  Titanium using all native cross-platform UI controls, so it builds both the iPhone and Android app from a single codebase and a single development effort.

The nice thing about SEMTab is that it makes extensive use of Titanium’s event system to fire off simultaneous asynchronous HTTP requests to the various web services and APIs to fetch data about the current domain you are checking. This prevents the application from locking up while fetching rank or share information, and it prevents the HTTP requests from stacking up in a queue and waiting for the ones in front of it to finish. The end result is a pretty slick & simple SEO app that gets the results you want quickly, without feeling sluggish or unresponsive.

Check out SEMTab SEO Pro in the App Store or the Android Market when you get the chance — and don’t forget to leave some feedback with a rating.

Zero to App in Two Weeks with Titanium

Like any web developer who has been sitting on the sidelines watching this mobile explosion happen in front of my eyes, I was eager to find a way to jump in. Up until about a month ago, I was still evaluating various different mobile development platforms – Titanium, PhoneGap, and Rhomobile, trying to decide which one I wanted to use to make my first mobile app. My only selection criteria was that the platform would have to be able to produce both iPhone and Android apps with the same code, because I wanted to be able to develop and release both an Android and iPhone apps without having to learn two completely different programming languages and development environments, and without having to do everything twice.
Continue reading

InvoiceMore Launch and Differentiation

invoicemore

InvoiceMore, the startup I have been working on in my spare time for over 7 months, has finally launched. This post actually comes a bit late to the party, because I actually launched InvoiceMore at OpenBeta on March 12, 2009 and blogged about it on the Actridge blog that day. I haven’t even had time to thinkabout sitting down to write this post on my personal blog about the launch until now. That’s a testament to how crazy busy my life has been since I decided to pour all my spare time into starting a business. So what is InvoiceMore, and how is it different?

moreInvoiceMore is an online billing and invoicing application aimed at freelancers and small businesses. It basically provides a super-simple web interface for creating and sending invoices to clients and recording payments for them. You can email and generate PDF invoices, print and snail mail them, and just keep track of your clients and their payments in a really easy and intuitive way. It was created based on my experience from a different billing application I created to fill my own client billing needs for freelance and contract work.

Differentiation

A lot of people ask me why I made InvoiceMore, and how it will be any different from what’s already out there on the market. If you’ve ever used an online billing application, or currently are using one, InvoiceMore works much the same way, with one major exception: Recurring billing. All of the online web-based billing applications I have come across so far do recurring billing the same way: a “recurring invoice template” that has a recurring interval set on it, like “1 month” or “2 weeks”. The problem is, if you have a client with multiple recurring services at different intervals, you have to setup multiple recurring invoice templates, and your client ends up getting more than one invoice per month at least a few months of the year.

Clients don’t ask for recurring Invoices. They ask for recurring products and services. An invoice is the natural end result of the products and services they buy. Competing billing applications make you create and setup what should be the end result: the Invoice. So to solve this problem, I built recurring billing in InvoiceMore in what I believe is a much more natural way: the products and services themselves. So with InvoiceMore, you associate products and services with clients and pick a recurring interval for that association. Then every billing cycle, invoices are automatically generated for that client from the recurring products and services that are due sometime within that billing period. You end up with a single invoice with everything due on it instead of multiple “recurring invoice templates” that are generated and sent independently.

So if you’re interested in learning more, you can try InvoiceMore out for free, or just read the information on the website . Let me know what you think in the comments here, or on the official UserVoice page for feedback and ideas.