Closed-System Thinking Strikes Apple Again

Once again, Apple is grasping for profits by closing the system. I'm sure it will work out about as well as their decision to make the Macintosh a closed architecture. The end result? The PC architecture took over 90% of the market.

Red Apple by Vera Kratochvil

This time, Apple is forcing developers of iOS apps who sell products through their applications to offer a purchase option through the Apple purchasing system. You can't sell anything through your app unless you also make it available through Apple so they can get their 30% cut. No more just sending them straight to your own Web site.

To be fair, Apple isn't changing the rules. This requirement has been part of their app development terms all along, but now they are enforcing it. The initial rejection of the Sony e-book app for failure to comply was a shot over the bow.

Sure, Apple has the right to set the rules for playing on their playground. If you want access to the users of their platform, you have to play by their rules. But if the rules become too onerous, the kids will just seek another playground that is less regulated.

History has shown that you have to keep the developers and the organizations who fund them happy with working in your environment. Forcing a 30% cut in margin may take the profit right out of the deal. They'll start looking for a more profitable option, which provides an excellent opportunity for Apple's competitors.

But unfortunately, Apple never learns. Their iBookStore is widely joked about for it's inconsistent availability of best selling titles. Why? Because they closed the pricing system with their insane "agency pricing model." Random House refused to play along, so the iBookStore (as of this writing) doesn't carry any titles from one of the largest of the "Big 6" publishers.

At least Apple was sneaky enough to let many developers release iOS apps that violated the terms for a while. Some of those apps have established a large user base, so Apple is effectively able to extort compliance out of the creators of those apps. It's either that or discontinue the app and lose the user base.

It will be interesting to see how Amazon reacts. According to the Codex Group, more iPad users buy their books from Amazon.com (40%) than from the iBookStore (29%), thanks to Amazon's Kindle app. To be fair to all players, Apple needs to apply the rules consistently, so they will have to reject the next Amazon.com Kindle app update unless it complies. Amazon is used to being the bully on the block, and hates being strong-armed itself, so the results of that battle will be fascinating.

It's possible Apple will get what they want this time and the proverbial shot will miss their foot. For consumer hand-held devices, they are the big kid on the block now. The odds of a competitor overcoming that advantage is realistically fairly low, regardless of how much Apple annoys app providers.

User Control City

I recently worked on an application that made extensive use of user controls to manage the its user interface. The application was essentially a long wizard, and each step of the wizard collected information through one or more user controls.

The design came about due to a business requirement that required extreme flexibility: the customer needed the ability to quickly change the design of any input area on any page, and wanted to be able to change the page on which the input area appeared. The development team was effectively building a live application in prototype mode.

Although each user control was fairly self-sufficient and could operate independently of the others for the most part, we obviously needed an orchestration framework that handled page sequencing, validation, and other housekeeping activities.

For example, the wizard's Previous and Next navigation buttons were handled by a user control that needed to trigger validation in the current page's user controls and handle the results of that validation. We chose to handle that requirement and similar requirements by adding events to the user controls.

The problem with the user control events is that many of them needed to send data to the attached event handlers and receive data from them as well. That requirement couldn't be handled with the standard EventArgs and EventHandler classes built into the .NET Framework.

Although we could have created custom delegates for the events, those delegates would require extra logic to wire up and would not behave like "normal" control events. For example, there'd be no way to wire up a handler through the control declaration in the hosting page.

A little research into event handling yielded the solution to our problem: we needed to use the EventHandler<TEventArgs> generic. This class is also built-in to the .NET Framework, and it is specifically designed to solve the problem we faced. Using the EventHandler generic, you can create a custom EventArgs class and pass variables back and forth between the class raising the event and the class handling the event. Eureka!

I've since used the technique in other projects as well, and every time I do so, I have to look up how it works and refer to previously-written code. Such is the non-intuitive nature of delegates.

I decided that such a useful technique should be better documented, so I put together an article on my NerdyMusings.com site that explains the steps for adding an event with custom event arguments to a user control:

How to Add Events with Custom Arguments to ASP.NET User Controls

I hope the article saves other developers who needs custom event arguments from having to piece together the solution for themselves.

A Plan for Happiness

One of my wife Susan's favorite quotes is...

Go confidently in the direction of your dreams. Live the life you imagined.

~ Henry David Thoreau

No problem, right? I'm sure you're doing it right now: your life is exactly what you imagined and you are going confidently in the direction of your dreams.

If that's true, you can stop reading right now. But I'm guessing that you started reading this post because of the title, and a plan for happiness would be a welcome change in your life.

If you break down Thoreau's quote, you can see exactly why you aren't already living the life you imagined. Three key concepts drive the process to getting there: confidence, direction, and imagination. The lack of any one is a roadblock that leaves you wandering uncertainly through a life of disappointment.

The first step to living the life you imagined is to have a dream. Many people have trouble articulating their dream life, but that's exactly where you must start in order to have a direction. Look at your life now and write down what makes you happy and what makes you unhappy. Those things are clues. Dig deeper by repeatedly asking "why" those things affect you like you do until the question starts to sound absurd. The first "because" answers you come up with are often intellectual masks for the true emotional reasons for your reactions to circumstance.

After you break down the things that make you happy and unhappy, assemble your happiness keys into a package that describes your dream life. Turn the package upside-down and sideways. Take it apart and put it back together again in different ways. Try mind mapping, or a vision board, or some other tool to help you bring it all together into a coherent picture of what you want your days to be like. That picture is your goal.

Having a goal is a good start, but you still have a huge gap between your goal and where you are now. Your goal gives you a direction, but traversing the gap requires a plan of action.

Many people never achieve their goals for the simple reason that they never make plans to reach them. At first, creating a plan seems hard because you are looking across the distance between where you are and where you want to be, and you can't see how to make the leap. The trick is to realize that you don't have to make that leap in a single bound. You don't even have to go in a straight line. Your best course may zig and zag. That's okay, as long as you know where you want to end up. It is often better to go around an obstacle than to try to go through or over it.

Develop a plan by working backward from your goal and forward from your current position until you can identify the next easily attainable step that gets you closer to your goal. Now, before you get too relaxed about having started an action plan, set a deadline for that next step. When you complete the first step, do the same thing for the next step. Don't expect to have all the information you need to come up with a complete plan from the beginning: just keep taking achievable steps that bring you closer to your goal. You'll just stress yourself out if you try to make a plan that encompasses obstacles you can't know about until you get there.

Having a goal and knowing what you will do next gives you confidence, the final necessary ingredient in your plan for happiness.

Confidence in your plan borrows happiness from the future. You'll find that the very act of going forward in the direction of your dreams helps you start to live the life you imagined before you even "get there." The journey itself becomes half the fun, which is good, because it may take you a while to get there.

Social Security for Social Media

I saw an interesting post from Seth Goden today (Sort of private) about a URL-shortening tool that adds a simple form of protection to the target link. The service Trick.ly calls itself a "magic url shortener," the magic being that you assign a password and a clue to the shortened URL. People who click the shortened URL must provide the correct password based on the clue in order to complete the redirection.

When I read the post, it occurred to me that it was inevitable that someone would apply a social form of security to social media. What is clever about this approach is that you can scale the level of security to the size of the audience you want to reach. For example, if you want only your family to see the redirected page, the clue would relate to something only your family would be likely to know (e.g. "What was grandpa Brashear's first name?"). You could also make the clue something only a person with specific interests would be likely to know, such as "what is a beer mixture called before it is fermented."

Another thing I like about this form of "social security" is that the technique is virtually bot-proof. You could set up a page that is linked ONLY through a "social security" tool such as Trick.ly, and web-crawling bots would have no way to directly reach that page. On the flip side, no page that is behind a Trick.ly URL will get spidered through the URL, which may be an unintended consequence.

A co-worker of mine once introduced me to a Hebrew word that has stuck with me since, and it applies in this situation: shibboleth. For my purposes, Wiktionary has the most appropriate definition, "A word, especially seen as a test, to distinguish someone as belonging to a particular nation, class, profession etc."

The cool thing about a shibboleth is that it lets you identify a specific group of people. It's like a secret pass code. It isn't exactly "secure" in most cases, since a dedicated person can probably just do a little research to find the answer to the clue. But those who are already "in the know" feel that satisfying sense of belonging that comes with having insider knowledge.

However, I think this approach could backfire if used as a marketing technique. Just as insiders get a little thrill out of knowing the answer, those who don't know the answer may feel alienated. You have to be very careful about how you use a shibboleth with prospects because it can come across as elitist and exclusionary just as easily as it could be seen as a clever gimmick.

Used properly, I think social security tools like Trick.ly have the potential to be another "fun" aspect of social interaction on the Web.

Five Critical Steps for Configuring an SMTP Mail Server

The most important thing you can do to protect the deliverability of your organization's email messages is to configure your mail server properly. More and more Internet Service Providers (ISPs) are rejecting messages based on improper mail server configuration, because an improper configuration is often an indication of a spammer at work. This article describes a few critical things you can do to prove that your messages are legitimate.

To demonstrate the following tips, I'll use a mythical mail server called smtp.mycompany.com. This mail server sends messages out through IP address 192.168.0.1.

Step 1: Assign an IP address and a dedicated domain name to the mail server.

Your SMTP mail server should have a dedicated domain name like smtp.mycompany.com. Avoid using the same domain name for your SMTP (outgoing) service and your POP3 (incoming) service, particularly if you think you might ever put them on separate IP addresses. Many organizations use something like mail.mycompany.com for the POP3 service and smtp.mycompany.com for the SMTP service. Just remember that an IP address can have multiple domain names associated with it, but a domain name can reference only one IP address.

In theory, it shouldn't matter if you dedicate an IP address to the SMTP service and nothing else, but it can't hurt to do so.

The action item for this step is to create the new subdomain host record (or an "A" record) in DNS and associate it with the IP address from which the service will send messages. In my case, I'd create an "smtp" subdomain and assign it to 192.168.0.1.

Step 2: Configure the mail server identity.

When you set up the SMTP service, put it on the IP address you selected and make sure the service identifies itself (sometimes called the "HELO" name) using the domain name you selected. In my example, the SMTP server at 192.168.0.1 identifies itself as "mail.mycompany.com."

Why are these first two steps important? Some receiving mail servers do a "HELO Lookup" to verify that the sending mail server is who it says it is. The receiver takes the domain name claimed by the sender and does a DNS lookup on that name. If the IP address that comes back from the lookup does not match the IP address the sender is using, the receiver rejects the message.

Step 3: Lock down message relay.

A "message relay" refers to when a computer connects to an SMTP server and hands it a message to send. For example, when you press the Send key in your mail client, you are "relaying" a message through your ISP's mail server.

Most SMTP services let you configure what IP addresses are allowed to connect and send messages. If you allow all IP addresses to connect, your server is considered an "open relay" and it will probably get found, abused, and then blacklisted very quickly.

Instead, limit the connections to known IP address ranges on your network. If the mail server will only be used to send messages from the local machine (web servers are sometimes set up this way), lock it down to allow only local connections.

Step 4: Enable reverse-DNS lookups.

DNS is normally thought of as a "forward lookup" service where the goal is to resolve an IP address from a domain name. Reverse DNS refers to the practice of resolving a domain name based on an IP address.

In order to configure a reverse lookup in DNS, you must be the registered owner of that IP address. Even if your ISP allows you to manage your own domain names, there's a good chance that you'll need their help in configuring a reverse lookup, because they "own" the IP addresses they are loaning you.

However you must manage it, the goal is to create a pointer (PTR) record in DNS. That record associates the IP address (192.168.0.1) with the domain name (smtp.mycompany.com).

The reason for this step is that some ISP's use a reverse DNS lookup to verify that the mail server's identity is agreed upon by both the owner of the IP address and the owner of the domain name. This filter is not widely used because it is slow and compliance is low.

Step 5: Configure an SPF record.

Sender Policy Framework (SPF) is a pseudo-standard that gives organizations a way to identify the domain names and IP addresses of authorized email servers. In other words, it gives the mythical "My Company" a way to identify mail servers that are allowed to send messages from the "mycompany.com" domain name.

SPF is a voluntary standard, and as such, a largely unreliable one. Many ISP's do not reject messages that fail to pass SPF testing, although they may pass along SPF test results in a custom message header (as of this writing, gmail does exactly that). That said, some ISP's DO reject messages that fail SPF, so it is a good idea to set up an SPF record for your organization.

Explaining how to set up SPF is an article in itself. The bottom line is that you need to set up an SPF and/or TXT record in DNS that contains SPF syntax for identifying valid mail senders. Just as an example, here's how the content of the MyCompany.com SFP record might look:

   v=spf1 a mx -all

That SPF instruction says to allow any sender that matches an existing A (host) or MX (mail exchange) record defined for the domain, and disallow all others. I set up a host record for smtp.MyCompany.com, so it should pass these rules.

Troubleshooting

If you run into difficulties implementing any of the above recommendations, you can use the following tools to troubleshoot:

Forward/Reverse DNS Lookup by ZoneEdit.com

SPF Record Testing Tools by Kitterman.com

Conclusion

I have to say that I really hate email. I love the idea of email, but the technical and political reality of email is enough to make you want to pull the plug on your computer forever.

The primary source of my loathing of all things email relates to the fact that I've had to help solve email delivery problems for large and small companies alike. I've also had to write a lot of program code relating to email automation and management. I say "had to" because this kind of work has never been my preference.

From a user and even a developer's viewpoint, email is pretty simple and easy to use. But from a system administrator's viewpoint, it is a nightmare. Spam is ultimately responsible for most of the angst. No government or technical intervention has been able to solve the real problem, which is that spammers are still able to exist. The reality is that we are all stuck with an antiquated and unsecure messaging network, and we have to resign ourselves to dealing with it.

I hope the suggestions I presented here will help you get your messages to their destinations and avoid getting blacklisted in the process.

A Lot of Transact-SQL Still Out There

I had a question from a reader of my Nerdy Musings site today about how to check for a missing stored procedure parameter in Transact-SQL. I sent him a response and decided to write a quick article about the subject:

Using Optional Stored Procedure Parameters

While answering his question, I thought about how much Transact-SQL is still out there in the world. Even though SQL Server lets you create stored procedures with the more robust .NET languages like C# and Visual Basic, there are still millions of lines of Transact-SQL code executing every day, and developers create more all the time.

In fact, my article on Coding Transactions in Transact-SQL consistently ranks in the top five articles on Nerdy Musings, and it is usually in the top two.

It just goes to show you that new technology does not make old technology any less useful. I would not be surprised if Microsoft eventually drops support for Transact-SQL, but for now, I can still take advantage of the hard-won skills I have developed in it and share my expertise with other developers who need help.

The Agency Model for Book Pricing Doesn't Make Sense

The major publishers are pushing their heads into the sand once again. They seem to think that books are special products that deserve different treatment than any other retail product. The Agency Model that Macmillan and Hachette have adopted is just another way of clinging to obsolete business rules. Granted, Amazon's reaction to Macmillan's ultimatum was a little over the top, but I think they have a stronger leg to stand on.

If you've been watching the publishing news, you know that Amazon removed the buy buttons from all Macmillan books on Friday, January 29 after Macmillan informed Amazon of their intention to go to an Agency Model for book pricing. Although negotiations started immediately, the buy buttons were still gone on most Macmillan books well into this week, at least.

In a nutshell, the agency model means that the publisher sets the retail price of the book and gives the retailer a commission. This approach gives the publisher control over the price of the book and lets them stabilize the payments that get made throughout the channel along the way to the customer's hands, including author royalties and the publisher's profit margin.

But does this approach make any sense? Not at all.

With most retail products, the manufacturer (or publisher in this case) sets a wholesale price and retailers are free to sell the product at whatever price they can get. The manufacturer controls the wholesale price and the retailer controls the retail price. Each is in control of their own profit margin.

Yes, the book market has legacy business arrangements like returns and author royalties that complicate matters, but those elements should be simplified and incorporated into the cost of goods sold.

From Amazon's perspective, the Agency Model dictates what they can charge for their products and puts publishers in charge of Amazon's profit margin. No wonder Amazon balked.

The whole point of a retailer is to provide service to the consumer. They do that through marketing efforts, convenience factors, and customer services. On the other hand, a wholesaler/manufacturer/publisher has made a conscious decision to make their money on bulk sales to resellers (business-to-business) rather than deal with consumers directly (business-to-consumer). Wholesale is a very different business from retail, and wholesalers have no business telling retailers how to run theirs.

To be fair, it works both ways. Retailers have no business telling wholesalers how to run their business either. Amazon, Wal*Mart, and other superstores have shown how messed-up things can get when they do. In the name of "customer service," these retailers abuse their power in the marketplace to force wholesalers into a pricing model that is often not sustainable. This is a case where the retailer is trying to take control of the wholesaler's margin. The customer benefits in the short run with lower prices, but loses in the long run when their choices are reduced to the few high-volume manufacturers who were able to compromise product quality and improve production efficiency enough to satisfy the mega-retailer's demands.

In many ways, Amazon itself inspired publishers to implement agency pricing. The publishers were reacting in part to Amazon's strong-arm tactics of establishing a market price of $9.99 for an e-book because "that's what customers are willing to pay." What they really mean is "that is the price that will give us the sales volume we want," which is not the same thing. The problem is that even Amazon admits that they don't make any money at that price. And they are trying to force the publishers to accept even less?!

I believe both sides need to stop screwing with each other and get back to the basics. Publishers need to set a wholesale price that covers their costs and gives them the margin they want. Retailers need to resell the product at a marked-up price that covers their costs and gives them the margin they want.

It really is that simple.