(I recently posted this thread to Apple’s
objc-language mailing list. I welcome feedback there or here.)
A recent Twitter conversation spurred me to think about how we use
super in Objective-C.
Here’s the letter I just sent to America’s Test Kitchen, informing them of why I canceled my trial membership and my complete lack of faith in their offerings.
Recently my coworker Tom was having a hard time with converting a Mac NIB to Auto Layout. The NIB contained a split view; on the left was an instance of
OACalendarView, and on the right was a scroll view. The holding priorities of the left and right panes were 251 and 250, respectively, and the scroll view had a required width constraint of greater-than-or-equal-to 150.
For some reason, the left pane insisted on being as wide as possible, squeezing the right pane down to 150 points wide. Dragging the splitter had no effect. How do we figure this one out?Continue reading
Up until three months ago, my time at the Omni Group had been spent programming solely for the Mac—I hadn’t written any iOS code professionally, and I’d only dabbled the slightest bit on the side.
That all changed when iOS 7 was announced, and I’ve now spent a solid three months as an iOS developer. For the most part, it was an easy transition; I’d picked up quite a bit of iOS knowledge peripherally, and I learned a lot more very quickly through hands-on experience. But one thing bedeviled me:
On Thursday, January 10, I gave a talk at Seattle Xcoders about Auto Layout, explaining the benefits and workings of this new technology and sharing some tips learned from our adoption of auto layout.
I’ve uploaded the slides from my talk.
I’ll upload the video once I’ve found a place to put it.
Update: Thanks to Paul Goracke of Seattle Xcoders, the video of my talk is now available as well. Unfortunately, for some reason the cursor got disassociated from the actual mouse position during the demos, and I don’t have any way to fix it. Sorry! (rdar://problem/13011198)
While his map is far more beautiful and informative, he credits me with inspiring him by producing a map I titled “Seattle on a Sheet.” I made this map in 2010, shortly after moving to Seattle, to help orient myself and flex my OmniGraffle skills. Unfortunately, all links to that file are now dead, as I’ve changed my online handle and web host since 2010.
Seeing that tweet spurred me to go looking for the original Seattle on a Sheet map, and after a brief trawling through Time Machine backups of a computer I’ve long since wiped and given to my mom, I found the map I thought was lost!
Here it is: Seattle on a Sheet.
edit: And now available in poster form from Zazzle!
I’ve uploaded my proposal for Objective-C namespaces to GitHub:
That will make it easier to track revisions and collate suggestions. If I ever have the time to work on a proof of concept implementation, I’d like to also add it to that repository.
Every three months I’m forced to change my Apple ID password. This means remembering to update every single iCloud-capable device I own (currently six and growing); if I don’t, my shared info like calendars gets out of sync and I, being the forgetful person I am, miss events and information.
On top of that, the Dev Programs login forms all have a ridiculous
onpaste attribute set so you can’t paste the passwords into the form. This means that on iOS I have to swap between 1Password and Safari to enter my password to log in.
I’m fed up with this stupidity. I just sent Dev Programs this nice little email:
When attempting to log in to the Developer Forums this morning, I was greeted with the all-to-common demand that I change my Apple ID password yet again. I find this demand infuriating, because I use a piece of software called 1Password to generate truly pseudorandom passwords. Every time I am forced to update my password, I have to then go around to every Apple device I own and update that password in all my iCloud account settings. If I forget a device, my calendars silently fail to synchronize and I miss important events. This is unacceptable.
But one of the other things 1Password does is allow me to copy and paste my cryptographically-secure passwords from the 1Password app into form fields. This makes generating and applying new passwords less painful. Alas, someone has made the decision that Apple’s developer login pages should prohibit pasting into the password field. This decision is not only the antithesis of Apple’s product ethos of setting up something correctly once and not having to modify it again, but actually decreases the security of the system. It discourages me from generating truly random passwords–instead, I must generate shorter, pronounceable passwords so I can remember them as I retype them. On the desktop, the 1Password Safari extension can modify the contents of the password field directly, but on iOS I have no recourse except to memorize and retype the password into the form.
This scheme is beyond user-hostile. It betrays extreme incompetence in that it actively encourages users to decrease the security of the system by encouraging the use of less cryptographically-secure passwords.
Again, so my message is crystal clear: forcing users to change passwords DECREASES the security of the system. Prohibiting users from pasting passwords into the login form DECREASES the security of the system.
Somehow, nobody else at my company is required to change their password on a regular basis. I am only aware of a few other developers that suffer the same counterproductive requirement to actively participate in harming the security of the ADC program. Not only do I want this ludicrous restriction lifted from my Apple ID, I want it lifted for EVERY other member of the Developer program.
UPDATE: Apple replied pretty darned quickly:
Thank you for contacting Apple Developer Support regarding Password requirements and restrictions. I am unable to change the password requirements and restrictions for your Developer Account.
We appreciate that you have taken the time to send us your feedback. Please be assured that all of your comments have been forwarded to the appropriate Apple team.
So WWDC 2012 was announced at early o’ clock and sold out in less than two hours. New restrictions on multiple purchases didn’t do anything to stave the ever-shortening window. As compensation for all the interested developers who won’t get to go to WWDC this year, Apple has promised to quickly post the session videos online (as they’ve done in the past few years).
Which leads me to ask: why is WWDC still worth attending? WWDC’s allure has always been the exclusive combination of three features: the sessions, the labs, and the social interaction with the worldwide Cocoa community. Now that the sessions can be gotten online mere days after the conference (and have lately been repeated locally during the Tech Talk series), and much of the community wasn’t even awake to purchase tickets, the only remaining feature of WWDC is the direct access to Apple engineers provided by the labs.
Maybe it’s time to think of a post-WWDC world. Or perhaps a world in which an event named WWDC still exists but bears no resemblance to the event we currently know.Continue reading