3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

I’m mostly agnostic about this, or at least I have three separate horses in this race:

• I’m a .NET developer by trade, so any tools that bring C# and VB.NET to another platform is awesome for me (I’ve long forgotten good ol’ C++ since college, and Objective C offends my sense of good use of punctuation).
• I’m an art photographer on weekends, so I live and breathe Adobe Lightroom and Photoshop.
• I’m a Mac fanboy. I switched out of curiosity when Apple moved to Intel, and I now own 3 Macs, 2 iPhones, and now an iPad (aka “Precious”).

Apple has a dozen reasons for their change in policy, including:

• Platform innovation – the desire to not allow third parties to weigh down the progress of a new, fast-moving platform with slowly-released, feature-limited translation layers.
• More developers in the Mac ecosystem – keeping developers on the Mac means more developers owning Macs and learning Cocoa and Objective C. Apple is betting that the incentive of the iP* market is strong enough to pull developers over. And once developers are there and learn the OS X / Cocoa / Objective-C world, writing apps for the iPad’s big brothers (Macs) isn’t much of a leap.
• Old rivalries – hitting Adobe where it hurts after Adobe’s half-hearted support of Apple’s devices over the last decade or so, and nipping in the bud Adobe’s product, which would only create a world of neutered Flash-tastic garbage on the App Store.
• User experience – Flash sucks. Touch screen or not, it’s best uses are video, virtual farming, and obtrusive advertising. The bugs, security issues, privacy issues, non-native UI, performance… who would wish that on users? (Granted, HTML5 has limits, including poor tool and browser support, even from Apple’s own web development tools and desktop browser.)
• Streamlined application review – Apple’s Stalin-like grip on application approvals requires them to probably have rooms filled with software developers looking through submitted applications, running them through lints and unit tests and human code-sniffing to separate the wheat from the chaff. I support that dedication to protecting their application marketplace, though (sidebar) I do think that App Store being the only way to install applications is anticompetitive and should be challenged in court. But if they are going to keep the bad apples out of their App Store basket, they need to be reviewing clean code in familiar, XCode-native languages.

But I think there’s a point that’s being missed in the debate:

Apple’s overall requirements can be met as long as what you submit to them is clear, non-obfuscated, commented C, C++, or Objective Code.

In other words, “originally written” is really none of their business, so long as the code they receive is straightforward and “looks like” someone did write it in native C, C++, or Objective C.

Code translators have been around for decades. It used to be relatively common practice (sorry, been out of the *nix dev space for awhile) that “compilers” for oddball languages (and some common ones like COBOL and Ada IIRC) were merely pre-processors that spit out C or C++ code for cc/gcc.

Granted, code converters traditionally produce slop code. They add redundant and silly code to flatten abstractions. They lose the original comments and variable names. They require libraries whose only purpose is to make the native APIs more accessible to the other language. They don’t necessarily make the best decisions.

But there’s no reason someone couldn’t come up with converter for, say, C# to Objective C. Rather than trying to hide the Cocoa Touch APIs behind a feature-limited set of Adapters, it should expose Cocoa in as native a way as C# can muster, so the developer has to learn the “zen” of Apple development. Thus, they stay “close to the metal,” but can continue to use a more familiar language (no +this, -that yuckiness).

This is a tough problem for some would-be contenders like Adobe Flash, since their development tools abstract the hell out of the platform so much, but would allow for a wider developer audience who don’t want to have to learn a new language, new IDE, and new base libraries all at once.

MonoTouch, from what I can tell, goes two steps too far. Hiding NSString and NSArray and the like is one thing, but trying to expose the Cocoa Touch APIs with shims that look like the .NET BCL creates the exact sort of situation I think Apple is trying to avoid. And, at least from what I can tell, it is a true compiler and produces bytecode, not code that can then move into the Apple toolchain. On the plus side, they do use the UIKit, so in the look-and-feel department, users can’t tell the difference.

If someone created such a converter, it shouldn’t be called a compiler or a cross-compiler, it would be more of a pre-processor, a very fancy macro language. In the end, it’s just inline function magic and syntactic sugar that allows C# developers to wade into Mac developer pool rather than being required to jump in head-first. (I think garbage collection and the nuances of the type system would be the hardest parts of C# to reproduce in clear Objective C, but I don’t think it would be impossible. But I digress.)

Like I said, Apple gets what they want:

• Developers are working directly with the APIs, even using another language. When Steve Jobs gets on the stage and talks about some new feature of CoreGraphics, developers won’t be sitting there wondering what part of System.Graphics he’s referring to.
• Developers still need a Mac with XCode to compile for simulations and tests on non-jailbroken devices.
• Apple still wins the moral victory over companies who would only offer a neutered, watered-down platform, especially companies like Adobe, who have a habit of only grudgingly updating their applications long after Apple has put old APIs out to pasture.
• Users win, since there’s no translation layer to hinder performance, and applications won’t be giving them an unfamiliar, buggy, non-native, “not quite right” experience.
• Apple retains the ability to effectively and efficiently review code coming in from developers, rather than getting cross-compiled binary crap from Adobe Flash, or 100 layers of abstraction from something like MonoTouch.

But most of all, developers aren’t locked into their current tools. A quality code translation means developers can take off the training wheels and start up XCode any time they want. Since they would still be using the “real” Cocoa Touch APIs, they wouldn’t be shackled by someone else’s outdated or incomplete interpretation of those APIs.

Apple needs to understand that a quick jump and a tight lid isn’t the only way to boil a frog.

Speaking as a developer myself, it hasn’t been the Cocoa framework that has kept me from developing for the iPhone, or having to learn XCode, or having to learn Objective C. The non-starter for me has been the combination of starting all three from scratch! I don’t have that sort of spare time, I have 100 other obligations and hobbies and personal projects.

The same goes for projects at work. I’d love to create a quick iPad-native version of some of the intranet tools I’m responsible for. There are probably hundreds of projects around the company that could make use of a mobile device like the iPad for data collection, but nearly always in offline-only environments. But no combination of projects has the time for me to jump off into the deep end, I need to be able to exploit the tools and knowledge I have in the .NET world to produce working applications with minimal overhead.

Give me the ability to tinker in C# and MonoDevelop and then test the generated code in XCode, however, and I might actually have time to learn Cocoa. Once I’m comfortable, I might even switch to Objective C, since I enjoy learning new languages (we programmers are masochists), and once I do that, I’d probably want to fire up XCode rather than compiling from the command line.

Hopefully someone will show Apple what a high-quality O-C or C++ translation would look like. Ideally, Apple’s code-screeners wouldn’t even know the difference. And that’s how everyone wins.

(Footnote: If Adobe would create a Flash compiler that compiles to HTML 5 and JavaScript that runs on WebKit and add some XCode-compilable stubs to manage state and browser windows, they too would be able to meet the letter of Apple’s law. But since that would prove that HTML5 is just as capable as Flash, I’m not going to hold my breath.)

(Edit: I wan’t aware of Unity3D except by name, since I’m not a game developer, but it appears their product does produce real Objective C converted from C#. From what I can tell, it still puts developers behind a shield that protects them from direct API access, it’s one step closer to something Apple should allow. Especially for games, where there’s not much use for native UI widgets, thus limiting the impact on user experience.)

(Edit 2: Apple’s approval of Opera is also a weak but good sign that they aren’t against bending their own rules, since Opera doesn’t use WebKit and has its own JavaScript interpreter.)

My own prices range from about $2k to $5k. Most weddings I book are in the $2,500-3,000 range and generally include an engagement portrait and bridal portrait session.

Questions to ask prospective photographers:

• Ask if they have professional liability insurance, including errors and omissions, and ask to see proof. Proof of insurance doesn’t mean you are litigious, it’s the same as if you were hiring a contractor to work on your house. Anyone without the insurance shouldn’t be in the business, period. For instance, what if a family member trips over a light cord and breaks their wrist?
• Ask if they use professional-grade equipment AND bring professional-grade backup equipment.
• Ask if you will be the only wedding they book that weekend. Photographers who overbook are more likely to lose focus, show up late or unprepared, and have technical drama. (Some photographers can hack it, but many can’t, and I can guarantee it’s a bad idea if you’re at the low-budget level.)
• Ask about their data backup strategy. The words “DVD” and “RAID” and “off-site” are good words to hear.
• Ask if you’ll get a copy of the photos, in full resolution, that you can make prints from, post on Facebook, etc. If the answer is “no,” expect to pay out the nose for any prints, you won’t have a digital backup for safekeeping, and you won’t be able to legally post any photos online for friends and family to see.
• Since you are focused on formals (a mistake IMHO–most people could care less about formals beyond the one “fireplace mantel shot” after the wedding), ask about what lighting they bring for formals. Lighting for a group photo should resemble a studio modeling shoot — bigger umbrellas and boxes.
• Look at an ENTIRE wedding they shot, not just choice photos from a few different weddings. Some photographers do great with flash or in outdoor or well-lit settings, but can’t shoot crap in a reception hall with poor lighting.
• Ask them the speed of their lenses. If they respond with a blank stare or if the numbers greater than f/2.8 comprise more than 1/4 of the lenses they say they bring, ditch ‘em.
• Ask for references. Check them.
• Ask yourself if the processing they are using will be timeless to look at in 50 years, or if it’s a cheap trick to create a trendy look (“vintage” film looks, cross-processing, etc.) and overcome lack of good exposure and composition. Just went to my wife’s grandparents’ 60th anniversary party, and sadly, their photos have kept their timeless quality better than some of my friends (still in their 20s).
• If they are qualified, ask photographers you’ve worked with as a model! I give model discounts since I know I’ll get a bride who isn’t camera shy and who I already have rapport with. If nothing else, they probably know the local market and be able to tell who is good and who is blowing smoke.

You get what you pay for, and the current climate of wedding photography is, unfortunately, like everyone with a decent oven opening a wedding cake bakery. There is a difference, no matter how much Cake Boss someone watches and tries to imitate.

1. Make it big. Really big. If you can’t produce something interesting, magnify the scale until it confuses the viewer into thinking there’s something really important about your piece that they are missing.
2. Take a long time. Rather than doing something that requires skill or has some important meaning or strong aesthetic, an “artist” will simply do something that makes it painfully clear that they spent a really long time constructing the piece. Installation art like is the worst offender. Making a 1/5-scale copy of the White House in Legos is impressive, but it says nothing about you as an artist or than you have too much time on your hands.
3. Make it complicated. Hide the lack of a strong concept in layers upon layers of random junk, hoping the end result looks like there’s more than there actually is.
4. Be trendy. Photographers are the worst about this. Rather than actually taking an interesting photograph, they rely on the crutch of faded and cross-processed color actions, Dragan filters, old film looks, and the Flickr-flavor-of-the-month.
5. Be offensive. True, offense is a sin of the viewer as much as the artist, but some “artists” are little more than visual shock jocks.

So, instead, I recommend the opposite:

1. Scale each piece for optimum viewing, not just to make an impression.
2. Challenge your technical skills with each piece.
3. Edit. Find the point where further complexity and layering no longer speaks to your concept, and stop.
4. Create the next trend.
5. If your art is not merely aesthetic, seek to educate and illuminate, rather than simply to offend. Understand your audience and bring them with you.

Without reading the judge’s opinion, I can’t decide for myself if he is correct.

But that’s why we have an appellate court system, so more experienced jurists can consider new arguments from lower courts and make sure our system is sound.

In the remote chance that there is a valid issue, I’m just glad the prisoner wasn’t already executed.

Of course, that may be his whole point — you might be able to let a guy out 20 years later if the next DNA-like technology exonerates him, but you can’t un-kill him.

Personally, I’m against the death penalty, but not on some emotional or religious grounds. I just don’t like:

• the necessary economic cost of a thorough prosecution (vs. one for life)
• the irreversibility of the sentence
• the real-world racial disparity of application of death penalty for the same crime
• the unsettled medical questions about the most common method of execution
• the error rate, proven by groups like the Innocence Project
• the dubious intelligence of the average “jury of one’s peers” these days
• the lack of evidence that it is a deterrent.

The whole thing just seems sloppy, inaccurate, unnecessary, and expensive.

However, those are probably not what this judge is making an argument, so either his logic will succeed or fail with the appeals court. Either way that’s one more settled argument, no harm done to test it out.

After hours of debugging, I think I’ve finally created a checklist that works to get a multi-light setup working with my AB800s, CSR+ receivers, CST transmitter, and CyberCommander controller.

• The CSR+ receivers don’t seem to work correctly when the polarity is reversed on the outlet, so check that. They may also be sensitive to an open ground.
• According to PCB, the lights need good 120V line voltage.
• Use the telephone patch cords that came with the receivers. Telephone cords from Radio Shack seem to not work correctly.
• Make sure the CC and CST have fresh batteries. The CC seems to eat batteries if you adjust light much.
• Put all lights on the same Frequency, different channels starting at “1″
• Plug the 1/8″ patch cables that came with the CSR+’s into the back of the lights, but NOT into the CSR+s. This disables the slave sensor. The CyberCommander setting to disable slave sensors does NOT appear to work correctly. Tape the other end of the patch cables so nothing contacts them and fires the lights accidentally.
• Turn all of the buttons ON on the back of the lights, and put the power slider at MAX (1/1).
• Turn the lights on FIRST, then plug in the patch cables (which should already be plugged into the CSR+s). This *may* fire the lights once, or may not.
• If the DUMP button doesn’t work, something is wrong.
• The connector on the bottom of the CyberCommander is loose. Put it in your pocket and use the CST on the camera hot shoe. This fires ALL lights using the last-known CC settings (the CC sends the settings to the CSR+s, not to the CST).
• Make sure the test button on the CSR+ fires the light. You may have to press hard.

Separate checklist for the CyberCommander:

• Make sure the bracketing settings are at -0.0f for all channels and groups
• Make sure the Frequency is set to the same as the CSR+’s
• Go into Spec Lights and make sure each light has the right device type and modeling light wattage. Set all unused channels to “None”
• When one light channel is selected, only that light should fire when using the test button on the CC, but the CST test button or camera shutter will fire all lights.
• I think the CC sends out an update to all lights when the Channel mode is set to ALL, so go there first and adjust the lights to get it to send baseline settings.
• Adjust each channel individually up and down, making sure the modeling light tracks with the power setting (after a delay of a second or so) and fires without firing the other lights.
• Move back to the ALL channel and make sure all lights are firing at the right levels. Quickest way to make sure all is well is take a shot at f/22, 1/160s, ISO 100 with the camera pointed at the lights.
• The CSR+’s seem to “remember” CC settings. I don’t know how long, but make sure you start bringing the CC to every shoot since you can’t adjust the light power when using the CSRs with the telephone cords and a CST transmitter (you can adjust the lights manually if you use the 1/8″ trigger cables, but then the CC can’t adjust them).

Hopefully that’ll either help someone else out there, or at least give me a checklist to work from in the future.

“We do not agree with their pricing strategy. I don’t believe that a new book by an author should ipso facto be less expensive electronically than it is in paper format.”

Fortunately for us, the market decides the price of products, not Ms. Reidy. This past week, there have been various other rumblings in the publishing industry, from Macmilan’s dispute with Amazon over pricing to the sky-is-falling predictions at recent publishing conferences, to the fearful reactions to Apple’s impending entry into the market.

Here are six reasons I do think that ebooks should be less expensive electronically than in paper format:

1. Cost of typesetting, printing, and returns is zero. This is the obvious one — electronic books cost nothing to produce, once you’ve converted the book to the appropriate formats. This impacts the publishing industry’s bottom line both for successful books (where there is a cost of printing and distributing each), and greatly reduces the financial risk of publishing an unsuccessful book (since bookstores aren’t returning unsold books for credit). These savings can and should be passed directly to consumers in a fair marketplace.
2. Electronic books can’t be shared or sold. We have, quite unfortunately, given up as consumers on forcing publishers to give us title to the books we buy electronically. Unlike a paper book, DRM technology locks up the books so we can’t resell them, give them to libraries, borrow them from libraries, or even share them with a friend for a few weeks. Publishers should realize that when they sell us a locked product that denies us the right of first sale, they are selling an inferior product with no residual value. That must be represented in the sale price, and should affect everyone’s profit up the chain, from the vendor to the publisher to the author. You can’t sell me a $20 electronic book over a $20 hardcover because the hardcover book has real residual value should I choose to part with it in the future. This goes double for textbooks.
3. eBooks allows publishers to reduce risk. While publishers still have to take on the risks of marketing, editing, carrying, and potentially providing non-refundable advances to the author, ebooks don’t require the same degree of risk planning to produce just the right number of books. Thus, electronic publishers can take on unknown authors (at lower royalty percentages) and works in niché subjects without the same risks as before. With long-tail economies, publishers can make more total profit on more works that sell, individually, much fewer copies than the big-name authors. This, in turn, will put publishers in a better position to negotiate with big-ticket authors.
4. Electronic publishing is green. Electronic books have a fraction of the environmental impact costs of paper books. This isn’t just about greenhouse gas, electronic publishing is also much more efficient when it comes to resource depletion (wood, water, and petroleum), acidification, and waste disposal. While our current lop-sided economic models rarely realize true environmental costs in the costs of goods sold, publishers should expect that these costs will hit them in the future in the form of regulations and pressures from forward-thinking distributors (like Wal-Mart), and the technologies they are either already putting in place or are planning to in the future to reduce environmental impacts can be side-stepped by paperless printing.
5. Cheap is the best way to combat free. Like it or not, paper books are getting easier to copy every day. Over 10 years ago, when I was in college, a number of students were known to all chip in to buy a textbook, run to Kinko’s and make $10 copies, and resell the original book. Now, they don’t even need the $10 apiece, just a few bucks for scanning. Textbook publishers were the first to be victims of piracy due to their ridiculous prices and the limited residual value of their books after the semester (due to an artificially-high rate of book revisions). Mass-market books and magazines are going to repeat the same mistakes as the music industry if they don’t learn the lesson that the easier way to combat piracy is to make it painless and inexpensive for people to obtain electronic versions of their works. Fortunately, competing with free doesn’t mean you have to be free–it just means you have to be “virtually free.” You have to hit people emotionally at a price that competes with frivolous entertainment and grande mochachinos. This is the reason that 30% of Amazon’s sales are electronic already, and iTunes sells more music than Wal-Mart.
6. The number of distributors is increasing. With Apple coming to the market, it’s time for publishers to not whine about the total price, but push for better deals from Amazon. Amazon’s costs for distribution are pretty cheap, and the more choices publishers have to reach people, the more distributors will have to do to court publishers. The best deal for consumers and publishers alike will be if Apple, like with iTunes, supports users putting works they didn’t publish through Apple in their iBooks library. While publishers not using Apple would lose the comfort of DRM, they would be able to keep access to Apple customers without being forced to take Apple’s deal. So, publishers should start now to push Apple to allow consumers to add unprotected EPUB files to their iBooks library, and thus keep themselves from becoming sharecroppers on Apple’s field, as they have been with the Kindle market.
7. Adapt or die. Number 7 is free of charge . Publishers have traditionally been the powerhouse for finding quality authors, funding their work, marketing it effectively, and managing the supply chain. Electronic publishing is already breaking down walls for independent publishers, who can contract with cost-effective contractors (a little plug for my brother’s company there) to produce quality ebooks, sell them directly (through Amazon or other web sites), and self-market them online. Sure, they may never sell a million copies, and 80% of self-published work aren’t worth the paper they aren’t printed on, but they are the new competition. If independent authors consistently meet or beat the prices of “published” works, new technologies will emerge to sort the wheat from the chaff, and people will find interesting independent authors to take up some of the relatively-fixed number of books they buy.

So, I encourage publishers to put some thought into where they want to be in 5 years. The reality is, it simply won’t involve nearly as many dead trees and ink-stained fingers, and they have an opportunity now to avoid the fear-driven missteps and heel-digging of the music and movie industries. Instead, they should focus on creating a marketplace with new profit opportunities and larger markets for themselves, while understanding that they simply must provide a better value for customers to survive.

Watching Jobs et al on stage yesterday, there were a few lingering questions I have that I hope Apple addresses before the release:

• Camera, pretty please? I’m hoping a front-facing camera is a “one more thing” added at the end. This does seem like a no-brainer, a 2MP camera would add $10 to the cost.
• No GPS for wifi users? Apparently only 3G customers get the GPS feature. I see what the issue is: (1) GPS without cell tower assistance can take 40 seconds to get a lock, and (2) 99% of the time, if you don’t know where you are, you don’t have wifi coverage. Hopefully the wifi-based location services will be good enough to at least get me in the neighborhood when I do have a wifi connection and I want to use the map, movie listings, etc.
• Sync? Is Apple going to provide a way for iPhone users to sync their app settings between the iPhone and iPad? Sure, it would require developers to make some changes to their code, but would be very handy for people with both.
• Number of devices? Our household already has five authorized devices for iTunes content: my iPhone and Delanea’s, my Mac Pro and her Macbook Pro, and the Mac Mini we use as an HTPC in our living room. Adding an iPad to that will require me to de-authorize one device, and I can’t make that choice. If Apple doesn’t expand the number of devices, I won’t be considering buying new locked iTunes content.
• Stylus? I know Apple wants to be all intimate with their iPad, but I want to take notes in a meeting without looking like I’m finger-painting. ThinkGeek sells styluses that work with the iPhone, will they also work with the iPad’s touch sensor? If so, maybe someone will write a note-taking app (I don’t care about handwriting recognition, just handwriting and the ability to get electronic signatures on documents).
• Magazines? The only magazines I subscribe to are fashion magazines. It would be nice to get rid of those dead trees and keep it all on one device, and bookmark pages I like. No news about any sort of periodical subscriptions for iBook during the demo, just the same old “look it’s a newspaper web site with columns!” demo.
• iTunes Plus content? Will the liner notes, etc. for the fancy iTunes albums be viewable on the iPad? Seems like a natural fit.
• Bluetooth keyboard support? Or will I be forced to use the dock-connected one when I already own a perfectly good bluetooth Apple keyboard?
• A4 Chip? So, is this thing instruction-compatible with the ARM processors used in the iPhone/iPod, or are they doing a little Rosetta magic on us? If the latter, I would expect iPad-specific compilation to result in better performance and longer battery life vs. running iPhone apps directly. What are they doing to allow apps to be downloaded with both iPhone and iPad native binaries?
• Keyboard-like accessories? The keyboard dock tells me there is a way for an accessory to use the 30-pin connector to emulate a keyboard. Looking forward to seeing devices like bar-code scanners and credit-card swipers that dock snugly to the bottom of the iPad and merely emulate a keyboard for data entry.
• Audio reading in iBook? Kindle has its computer read-aloud feature, and while it caused a stink with stingy publishers, it is a useful feature. If Apple isn’t going to add accessibility features like this to the iPad, will they at least work with publishers to “bundle” audiobook versions of books with the ebooks? It would absolutely rock if the user had the choice to switch back and forth between a human-read audiobook and an ebook format, or even have them running simultaneously.
• Voice control? iPhone has it, and iPad has a microphone. So, will we be able to control our iPad by voice command? Please say yes.
• Free book library? iTunes has some free content, so does the App Store. Google offers more than 1 million public domain books in ePub format. Will we be able to get to these through the iBooks store, or at least add them manually?
• iBook on iPhone? I have used the Kindle app on my iPhone to read a few books, so will Apple offer similar functionality so those without the iPad can still enjoy the convenience of the iBook store?
• Kindle for iPad? Speaking of the the Kindle iPhone app, will Amazon upgrade the app for iPad use, and will Apple approve it? It would be smart for both of them — Apple needs to woo Kindle users who’ve already amassed a library, and Amazon’s unsexy etch-a-sketch is going to start losing the important market share (the books, not the reader) to the iPad at some point.
• SVG? Come on guys, Safari supports it on Mac and Windows. Can’t be that hard to give us iPad/iPhone support for scalable images! And it would shut up most of the whining about Flash (which I have absolutely no interest in seeing added to the iPad or iPhone).

Ok, that’s it for now. Guess we’ll see in the coming weeks how all this pans out. Despite a few small disappointments, I will be among the first in line for an iPad. I’ve been waiting for it since I was a kid watching the PADDs on Star Trek: The Next Generation.

Apparently I bought one of the last Saturns. #

Powered by Twitter Tools.

Powered by Twitter Tools.

Powered by Twitter Tools.

Powered by Twitter Tools.

Powered by Twitter Tools.