To accomplish these tasks, I have written a couple of classes that are intended to simplify things. Rather than completely reinventing the wheel, I started with the excellent open source SubnetCalc project by Ramond Ferguson. I adapted the existing code into an object-oriented class structure, and updated the regular expression handling to use the superior preg_* functions to improve speed and future compatibility, as ereg has been deprecated. In addition to the detailed subnet calculation functions already offered by the project, I have added a few new features:

• Test if a given IP is a valid address
• Determine IP type (node, network, or broadcast) based on the associated subnet schema
• Test whether an IP is within in the subnet’s address range
• Dynamically alter the subnet schema — calculations are automatically updated to the new values

They always say the proof is in the pudding, so here are a couple of usage examples. First, let’s create an IP object. The class will automatically test to see that the IP is valid, and throw an exception if it’s not:

try {
	$ip = new IPAddress('192.168.1.12');
} catch( Exception $e ) {
	print $e;
}

To assign a subnet mask, you can call the SetCIDR method:

$ip->Subnet->SetCIDR(24);

And now your object is populated with a handful of useful calculations:

IPAddress Object
(
    [Address] => 192.168.1.12
    [Subnet] => Subnet Object
        (
            [Class] => C
            [Netmask] => 255.255.255.0
            [CIDR] => 24
            [Wildcard] => 0.0.0.255
            [Network] => 192.168.1.0
            [Broadcast] => 192.168.1.255
            [FirstHost] => 192.168.1.1
            [LastHost] => 192.168.1.254
            [Hosts] => 254
            [Private] => 1
        )

)

You can also use the Subnet object by itself to perform simple calculations without a specific IP address, and you can call the IsValidHost() method to test an IP address to see if it fits in the subnet. An example of how this might look:

try {
	$subnet = new Subnet("192.168.1.0/27");
        print $subnet->IsValidHost("192.168.1.21") ? "YES" : "NO";
        print $subnet->IsValidHost("192.168.1.64") ? "YES" : "NO";
} catch( Exception $e ) {
	print $e;
}

In this example, a subnet is created, with possible hosts from 192.168.1.1 to 192.168.1.30. So the first print statement would display “YES”, since node 21 falls within the subnet, and the second statement would display “NO”, as node 64 is not part of the subnet.

If you would like to try these out for yourself, you can download the classes here. Thus far, the class seems to work well for my purposes, but as this is based on some unfamiliar code from another project, I could have easily missed something. I will continue to fine tune the code, and will be doing some minor cleanup on the imported functions as time permits, so be sure to check back periodically for any updates.

The way refunds are handled is explained (very clearly) in the developer agreement, and each developer signs and agrees to that agreement. What you don’t do is, knowingly sign a contract and then complain about the terms. What you DO do is, don’t sign the contract at all if you don’t like it.

Every developer knew – before they signed – that the refund process meant they could be refunding more than 100% of their revenue. Their only two options – complain and don’t sign, or sign and don’t complain. Those who sign and complain have only themselves to blame, they KNOWINGLY signed up to this deal!

Actually, if I remember correctly, for many developers the refund option didn’t even exist initially, and many developers were upset when it appeared in a later update to the agreement.

Either way, it’s a good point, since developers pretty much do agree to those terms just like many consumers agree to ridiculous terms on credit cards, and then complain when they are hit with huge fees because they didn’t actually read what they were agreeing to. And in this case, it’s no fault of Apple’s if the dev didn’t read their agreement. Luckily, in most cases, it doesn’t appear that Apple enforces it anyways.

I do believe, personally, that users should only ever get from the developers the amount the devs have actually been paid, and no more, but then, I didn’t sign the agreement, hey.

“And yes, there are over 10,000 developers, 65,000 apps, 40 million devices, and 1 billion downloads from the App Store. But none of that matters unless you realize that the developers themselves are directly responsible for much of the iPhone’s success. By alienating those developers through inconsistent policy handling and refusal to communicate one-on-one with them to resolve problems, Apple is setting itself up for failure.”

I disagree with this. I think it *does* matter that 10,000 devs have made 65,000 apps without much hassle, and yet the number of rejections and complaints is … what? A dozen? A few dozen?

Okay, I could have used better wording instead of saying “It doesn’t matter,” but I think you underestimate the number of rejections and complaints that actually happen. Yes, when compared to the total number of 65,000 apps, even saying as many as maybe (just throwing a number out there) 5,000 of those apps were rejected seems insignificant.

But looking at it from a different angle, we here at TUAW get a good number of e-mails regarding apps that were rejected or complaints about the approval process on a DAILY basis. Yeah, some are repeats and some days are more than others, but still, there is a much larger volume of rejections and complaints than what actually gets covered in the media.

I think it is very important for you to put things in context, otherwise you are misrepresenting the true situation – you’ve basically made it sound, from the article, that all developers have a problem with Apple, when in fact, we’ve only heard that a dozen or so do (out of 10,000 – that is a very small percentage!)

Agreed. But what I believe the real problem is doesn’t lie in the number of developers affected, as much as in the significance of the problems those developers have faced.

If it were just a handful of devs getting apps rejected for blatantly violating terms of the SDK, I don’t think there’d really be much to complain about, and we wouldn’t be having this discussion. But what’s happening is individual developers hit snags with Apple, where they follow all of the rules but, for one reason or another, Apple removes/rejects their app or some other problem arises that makes everyone stop and wonder what is going on.

And it is here that Apple stumbles, because they don’t deal with the problem in an efficient manner, they usually either give vague, inconsistent responses to the developer, or they choose not to communicate at all. Then the developer gets upset, the media gets involved and it becomes a big PR nightmare, and only then does Apple (sometimes) step in and make an attempt to remedy the situation. But by that time, the damage is already done.

I also disagree with the overall tone of the article which suggests that Apple benefits from developers while developers do not benefit from Apple at all.

That’s not the tone I intended, so I apologize if that’s what you’re getting from it. The intention was to express and convey the frustration with Apple’s decision to pull the GV apps, and claim that they were “duplicating functionality” rather than being open and honest with developers about the true reasons for their removal and offering methods of recourse; their lack of communication to the parties involved when they encountered the problem; and the effects of penalizing the developers with refunds for a decision that really was not the developer’s fault.

No developer designed, created and marketed the iPhone and App Store. That was Apple. But developers have been able to use this new market to make money – we know that some devs have profited (and profited well) from the App Store. So I think it is abundantly clear that devs have benefited from Apple as well as the reverse.

Completely agree.

Lastly, I don’t agree that Apple is setting themselves up for failure – I remember similar comments about Nintendo abandoning the polygon count race, and we know how that turned out.

Sometimes, decisions that look wrong on first glance, turn out to be right. This has been true of Apple in the past. It was wrong for Apple to launch a smartphone without copy-and-paste, without multitasking, without a replaceable battery, wasn’t it? More like 40 million points of right. Apple correctly identified what people wanted and needed, while most everyone else fell over themselves declaring that Apple had set themselves up for failure.

This can be interpreted very differently, depending on how you define failure. Do I think that the App Store will collapse, killing the viability of the iPhone platform and destroy the future of Apple? Definitely not. But I think that it is reasonable to believe the App Store (and by effect, Apple) could ultimately be less successful as a result of these problems. Sure, they might have achieved their goal to create a viable platform that allows developers to easily create apps and users to easily find those apps, but the attitude they choose to use when interacting with developers and dealing with problems harbors more dissent and unwelcome feelings among the community, which has proven to be detrimental to many platforms over the years.

I think you are discounting how much the iPhone’s and iPod Touch’s stability and friendliness comes from Apple’s “crazy” rules and the heavy-handed imposition of them, and I think you are blatantly assuming that Apple has had no reason to ever pull and reject apps. Apple might not be saying, but that does not mean that they don’t have a reason and that it isn’t a good one.

Valid points, though I don’t assume that Apple has had no reason to pull or reject apps. My contention lies in the fact that they hide their reasons behind vague and inconsistent policies. If you’re going to reject application X for having a particular feature, then you need to reject applications Y and Z if they have the exact same feature. To me, it’s fine if they have to pull an app from the store, but they need to take the developer of the app aside, and explain to them exactly why it is being pulled, and what options of recourse they might have to prevent it (if the pulling is due to a specific element of the application).

I mean, seriously, the developer is already under an NDA, so just remind them that under the terms of that NDA, they cannot disclose the reason the app was pulled to the public, and take them to court if they leak the details. And, if for some reason Apple simply *can’t* disclose to the developer their reasoning, don’t hide behind a vague claim that is obviously untrue, but instead tell the developer outright that they are unable to disclose the details, and then offer an olive branch to them by suggesting some form of recourse or compensation or *something* for the trouble.

But yeah, I agree that they might have reasons that they are not willing to discuss. And if they are going somewhere with those reasons, that’s fine. But they still need to keep an open line of communication to the developers. Even if that just means someone calling them up or sending a personal e-mail an saying something like this:

“Look, I’m really sorry, but we have to pull your app from the store. You didn’t do anything wrong, but we have to remove it for technical reasons. I’m afraid I can’t go into details at this time, but we will do our best to let you know if and when it can be resubmitted. I realize that you have put a lot of time and effort into this application, and due to the circumstances, we are willing to offer you ________________. In exchange, we ask you to keep the terms of this arrangement confidential, please inform users that the application had to be removed due to technical difficulties. In the event that refunds are requested, we will work with you on those cases.”

To me, a simple conversation like that would go A LONG WAY to keeping good spirits about the situation. Yes, it would still be a bit frustrating, but at least you’d have the feeling that *someone* at Apple actually cared, which unfortunately, doesn’t seem to be the case with many of these stories.

Ok, I’m done now.

$Report = new Report( “My Report” );

if (isset($_GET['format'])) {

$Report->Type = $_GET['format'];

}

$Report->Columns = array(“Employee”, “Department”, “Salary”);

foreach ($Employees as $Employee) {

$Report->Rows[] = array($Employee->Name, $Employee->Department, $Employee->Salary);

}

$Report->Display();

Recently, I have been tasked having to generate several reports containing various metrics, and then export these into an Excel sheet so that the data can be processed further.  I also occasionally get requests for data in a CSV format that can be imported into another system.  And these are just for the one-off reports… most of the standard reporting tools I have written produce data in an XML format, which is then procssed by an AJAX frontend and displayed in an HTML table to the user.  Talk about messy.
So this morning, I finally sat down and wrote out a report abstraction class that has been floating around in my head for the past couple of months.  Rather than have to worry about writing display code when building a report, I can simply deal with the data and hand it over to the class for display processing:

$Report = new Report( “My Report” );
if (isset($_GET['format'])) {
                 $Report->Type = $_GET['format'];
        }
        
$Report->Columns = array(“Employee”, “Department”, “Salary”);
        foreach ($Employees as $Employee) {
                $Report->Rows[] = array($Employee->Name, $Employee->Department, $Employee->Salary);
        }
        $Report->Display();

From there, the class takes the type identifier (which in this case is being selected by the user and passed in the URL), and provides the data in the correct format.  The class itself is fairly small, weighing in with less than 200 lines of code, but can display data in Excel, CSV, XML, HTML, or PDF, as well as a printer-optimized layout if the data is intended to be printed instead of displayed on-screen.