Oh Snap!
Posted at September 20, 2005 11:49 AM - Category: ASObill
Looks like I spoke too soon!
Come In, It's Open!
Posted at September 19, 2005 01:49 AM - Category: ASObill
So, I said I'd make an announcement regarding ASObill on the ASO forums. I suppose I should pre-announce things here and maybe see how the intial response is.
While I've been working on ASObill, I've been trying to work out where I want to go with the application for the first version and for future versions. My first plan of attack is against webhost-centric scripts, such as ModernBill and ClientExec. I've yet to see a decent billing script, paid or free, and see it as a BIG area for improvment in the industry. With these systems the general application architecture is a frontend order form with a backend customer relation managent (CRM) system. And that's where I intend to go with version 1.0. With future versions, my intent is to start going after the general storefront market and expand the frontend portion of the application to include more robust functionality. My main competitor is OSCommerce, which is a horrible mess of code from my experiences with it. So, it also represents a BIG area for improvment.
To get market leadership, having the best product doesn't necessarily guarantee the #1 spot. Apple has shown how this works. The real way to convince people (especially in the webhosting world) is on price. High quality at a low price is the fast track to gaining a large adoption rate. So, I could lowball the competitors and offer the product for a price point lower than theirs, but I don't think that's the way to go. That's not going to provide for a good support team and won't necessarily convince people. Instead, I have a better idea:
Open Source
Yep, ASObill will be 100% free as in beer and free as in speech. I'm not sure which license I'm going to use just yet (probably not GPL, maybe the MPL, maybe my own!), but it will be one that allows free redistrobution and use of the script.
Of course, where's the money in open source? Well, obviously it's not in the core product. You can maybe get donations going, but I don't see Novell or RedHat getting many donations nowadays. Instead, the money is in two things: Support and extensions. Obviously support is going to be something we can sell, but the extensions are the neat part. ASObill has been designed from the start to be extensible, so I intend to use that extensibility to make money. That doesn't mean that ability to sell products will cost, but some extraneous things definitely will. At its core, ASObill will offer billing services, including ordering, invoicing, billing, and customer management. What I intend to sell on top of that are automation plugins. Control panel integration, domain registration, credit card processor integration, etc. Given that it's an open source app, there's not much I can do the stop people from supplementing with free versions, but that certainly makes the coding more exciting and the competition just benefits the end-users, as well. In addition, ASO gets more airtime for free and there's a supplemental halo effect, much like the iPod halo effect on Apple's Mac computers.
So, I could either try to weasel our way into the market with a good product and try to make a ton of money, or I could give it away for free to the benefit of everyone. I think the choice is obvious. Besides, I've already got enough money with ASO :P
Peak-Based Provisioning
Posted at September 4, 2005 02:00 AM - Category: ASObill
I've been extremely distracted by my colocation plans, so ASObill development has been halted for the moment. However, that hasn't stopped me from thinking about it. The newest idea I've come up with: peak-Based provisioning.
Most other billing software out there that includes control panel integration fills up servers based on a set number of maximum accounts. As a result, the assumption is made that the activity and load generated by each account is constant. In reality, load varies greatly among accounts. So, my initial plan was to build in a load monitoring system into ASObill to monitor load and fill up servers based on system load. This solves the basic problem of overfilling servers and allows for much more automated account provisioning.
However, it's somewhat inefficient because sites often follow a curve of activity between day and night for whatever group of visitors to that site are most popular. Normally, servers are most active during the day in the US and the least active at night. However, there are many sites that peak at different times of the day. And, even in the load-based provisioning system, there is no accounting for this difference in activity.
Improved efficiency in systems would be gained if a site owner could select the time their site is most active and be placed on a server that has the least amount of activity during that time of day. Both sides benefit in this format. The host gets more sites per server or better use of resources on each machine, and the site owner gets a site that is faster when the power is needed most.
Using the order modifier system I've got in place within ASObill, this sort of stuff is simple to implement (although, the math isn't going to be that simple...). I love all this cool stuff I'm building within the ASObill framework. Almost more than the end-user application itself :D
Re-Refactor
Posted at August 24, 2005 09:48 PM - Category: ASObill
I've been sick for the past few days and I'm finally snapping out of it. Luckily, with the line of work I'm in, as long as I get a decent enough amount of sleep, I'm still able to function (although, I probably don't look that good to other people). During this time, I've been working extensively on ASObill now that we have most of the kinks worked out with ASO's new VPS offerings.
The biggest thing I've been doing is refactoring the code to remove almost all the redundancies I've been building up into my code. The basic format of a request sent to ASObill used to be like this:
- Load up the appropriate module
- Have the module determine which method to run for the particular input passed to it.
- In the method, check the input to handle blank values (in case there is an error with a form submission and we're heading back to the form with the error).
- Do whatever awesomeness the function is designed to do.
- Print out the appropriate template.
It doesn't look that bad from a distance, but there's a lot of repetition for each module and between the methods of a module. I was re-doing the full input validation for every module and having to manage the template output, as well. What I've done to relieve most of this work is take some cues from Rails. Look at this basic bit of Ruby code from a very simple Rails app:
def list
class DemoController < ApplicationController
scaffold :recipe
def list
@recipes = Recipe.find_all
end
end
What's nice is you don't have to tell the application which method to call in the class, it takes that from the input automatically. There is also no need to define a template. Input does happen to be ignored in this example, but it's also handled very simply.
Now, here's a similar function from ASObill:
class Products extends Module
{
function showproducts()
{
$this->db->query( "SELECT * FROM ab_products" );
while( $p = $db->fetch_array() )
$this->out['products'][] = $p;
}
}
This is a slice of the code, not the full thing, but you get the point. Aside from my odd code formatting (Hey, I'm used to it!), it's exercising much of the same efficiency you get with Rails. You don't have to tell it which method to call, it's found via the parent Method class. That same parent class also figures out the right template to output. I'm using Smarty for templating, so the loop needed to print out each product is stored in the template itself.
As a result, I've cut the core module code by 40%! Quite a substantial gain. I've also simplified development because there's less scrolling through code and less complexity in the methods. I've got to expand the database mode to add some better functionality (such as findall()), similar to ActiveRecord. However the biggest thing is that it's gotten me feeling much better about the direction of the application. I've debated switching to Rails, just because of the buzz it's generated. But this method lets me get all the functionality and productivity with wide-spread support of PHP.
Plug It In
Posted at August 15, 2005 04:22 PM - Category: Coding
The other day I found this neat little tool called MyGuestmap. To sum it up, it's basically a guestbook and Google Map rolled into one. Provided with a lot of users, you get something like Neowin's guestmap(Warning: It's a little slow to load with all the people we have).
While the implementation is simple (actually, really simple), it's a cool concept that shows the power of build extensible applications. Google Maps has an API they've built to allow developers to make use of the mapping service in their own applications or websites. Google Maps itself is relatively simple tool, but it serves as a great basis for other applications built on top of it.
This is the sort of stance I'm trying to take with ASObill. I can only dream up so many cool uses of the application, but if I give access for others to put in their own code on top of that, all sorts of neat things could be built up. Modularity and extensibility are the key parts of this goal. I'm making as much as I can either a module or plugin to the overall system. This is sort of a given with the sheer number of payment processing systems, server control panels, and other external ASPs we need to support, but it's also about going beyond just that. Inter-plugin support is something I'm going to be concentrating on.
Let me give a real world example for this: In addition to our reseller hosting accounts, ASO is going to offer some sort of discounted or free copy of ASObill with the price. So, when processing the order, it would be ideal if we could have a plugin that will create the account, one that will add the reseller account, and one that will install a copy of ASObill (a mini-Fantastico, if you will). So, I have one plugin for the main hosting account purchase and two addon plugins for the reseller access and the ASObill purchase. There's a whole lot of logic that goes into that. Discounts have to be accounted for. Addons have to detect other addons and the main purchase plugin. That sort of thing.
This is kind of why I really like coding ASObill and really hate coding ASObill. It's interesting but confusing as heck at times.
