Tim Cook Should Ignore Ars Technica (Almost) Completely

I came across this article by Jacqui Cheng and thought I’d add my two cents on each of the suggestions.

10. License OS X.  Despite the article’s protestations that licensing doesn’t have to be the disaster it was for them in the 90s, this suggestion misses the mark because it misunderstands what kind of company Apple–a hardware company.  Licensing OS X would only send hardware revenue to a company (or companies) other than Apple.  There’s no compelling reason for them to give away that money.  Licensing the OS won’t get them additional users, or revenue, or get them into some new market they might want to enter.  This is by far the worst idea on the list.

9. Bring some manufacturing jobs back to the U.S.  It’s a nice idea in theory, but in reality, there’s no compelling reason for them to do this.  Why  should they voluntarily raise their costs and reduce their profit margins?  Apple is hardly the only company doing business with Foxconn.  Dell, H-P, Cisco, Intel and Cisco are also major customers.

8. Invest in an independent research lab.  This has been said better by others, but Apple’s success is due in large part to its narrow focus.  People and capital used for such a lab wouldn’t be available to help with the things that Apple is great at.  There are other ways that Apple can contribute to the public good without directing a ton of money toward basic research.  In my view, the federal government is the right entity to be doing that (but that’s a whole other discussion).

7. More transparency on OS X and Mac plans.  Like suggestion 10, the primary focus of this suggestion seems to be on Mac Pro users.  It’s true that the Mac Pro hasn’t gotten much attention from Apple over the past couple of years.  Perhaps the biggest reason is that it doesn’t account for much of their revenue anymore.  The one point I would extrapolate from their suggestion that I would agree with is that Apple can definitely improve in how they treat developers for their platforms.  I’ve spent my career writing desktop and web applications on and for various versions of Windows, and Microsoft seems much more “pro-developer” (more information about development tools, free copies of software, training events, etc).  I wouldn’t expect Apple to try and become just like Microsoft in this regard (nor should they), but there are definitely some lessons Apple could learn.

6. Make the Apple TV more than a hobby.  This is the first suggestion in the list that I like.  I like the Apple TV enough that I own one for each TV in my house and have started buying them as gifts for family.

5. Offer streaming, subscription music.  I’m not sure what I think of this suggestion.  I avoided subscription music services in favor of buying music for years because I preferred the idea of owning it and being able to listen to it on whatever device I wanted.  I like the experience I’ve had with Spotify so far, but I don’t know if I listen to enough music to justify the monthly cost.  I’m not sure what Apple could bring to the space that would be better.  Whether they do anything with streaming or not, what Apple really needs to do is re-think iTunes.  As Apple has offered more and more content, iTunes has become more of a sprawling mess.

4. Inject some steroids into the Mac line.  I disagree with this suggestion completely.  Apple got it right with their focus on battery life and enough speed.  In mobile phones and tablets, seemingly every manufacturer using Android as the OS focused on metrics like processor speed, camera megapixels, and features like full multi-tasking.  The result: devices that had to be recharged multiple times over the course of a day.  By contrast, the iPhone is plenty fast, but I can go a full day without having to recharge it.  Multiple days can go by before I need to recharge the iPad.  Apple has correctly avoided competing on specific measures like processor speed and how many megapixels their cameras have.  They’re competing (and winning) on the experience of using their products.

3. Diversify the iOS product line.  If the rumors are correct, Apple will be offering a smaller version of the iPad soon.  The next iPhone will probably have a larger screen as well.  But beyond those changes, I don’t think Apple should be in any hurry to diversify in the way Ars Technica suggests.  By limiting the differentiation of their iOS-based products to storage size (and cost), Apple has chosen a metric that is both meaningful and easy for the typical consumer to understand.  This makes Apple products easier to buy than the alternatives.

2. Make a larger commitment to OS security.  I agree with this suggestion as well.  Apple’s success in the market has made them big enough for virus/malware makers to spend time targeting.

1. Cater to power users again.  I see this suggestion as a variation on the them of suggestion 7.  I’m sure Apple could do something like this in a way that wouldn’t disrupt their current approach.  Whether or not it would net them enough additional customers and revenue to be worthwhile is another discussion.

Help Build a Tesla Museum

One of my favorite cartoonists, Matthew Inman, is using his unique brand of humor to help raise funds to buy the site of Nikola Tesla’s old lab.  As of this post, he’s raised nearly $970,000.  I don’t contribute to a lot of causes beyond my church and public radio, but I contributed to this project because the U.S. could use a museum about a great scientist a lot more than another mall.  If you agree, I hope you’ll donate as well.

Introducing AutoPoco

I first learned about AutoPoco from this blog post by Scott Hanselman.  But it wasn’t until earlier this spring that I had an opportunity to use it.  I’d started a new job at the end of March, and in the process of getting familiar with the code base on my first project, I came across the code they used to generate test data.  I used AutoPoco to generate a much larger set of realistic-looking test data than was previously available.

Last week, I gave a presentation to my local .NET user group (RockNUG) on the framework.  The slide deck I put together is available here, and there’s some demo code here.  The rest of this blog post will speak to the following question (or a rather rough paraphrase of it) that came up during a demo: is it possible to generate instances of a class with an attribute that has a wide range of values, save one?

The demo that prompted this question is in the AddressTest.cs class in the demo code I linked to earlier.  In that class, the second test (Generate100InstanceOfAddressWithImpose) gives 50 of the 100 addresses a zip code of 20905 and a state of Maryland.  The possible objective of the question could be to generate a set of data with every state except one.

After taking a closer look at the documentation, and a review of the AutoPoco source code for generating random states, I came up with an answer.  The Generate1000InstancesOfAddressWithNoneInMaryland test not only excludes Maryland from the state property, it uses abbreviations instead of the full state name.  The implementation of CustomUsStatesSource.Next adds a couple of loops (one if abbreviations are used, one if not) that keep generating random indexes if the resulting state is contained in the list of states to exclude.

The ability to pass parameters to custom datasources in order to control what type of test data is generated is an incredibly useful feature.  In the work I did on my project’s test generator, I used the capability in order to create a base datasource that generated numeric strings with the length controlled by parameters.  This allow me to implement new datasources for custom ids in the application by inheriting from the base and specifying those parameters in the constructor.

Because AutoPoco is open source, if your project has specific needs, you can simply fork it and customize as you wish.  Another value-add of a framework like this could be realized if you write multiple applications that share data.  In such a scenario, test data becomes a corporate resource, with different sets generated and made available according to the scenarios being tested.

Another advantage of AutoPoco for test generation is that its use of plain old CLR objects keeps it independent of specific database technologies.  I’m currently using AutoPoco with RavenDB; it will work just as well with the database technology (or ORM) of your choosing–Entity Framework, NHibernate, SQL Server, Oracle, etc.

AutoPoco is available via NuGet, so it’s very easy to add to whatever test assemblies you’ve currently got in your solutions.  As long as you have public, no-arg constructors for the CLR objects (since AutoPoco uses reflection to work), you can generate large volumes of realistic-looking test data in virtually no time.