Happy coding!
]]>
Happy coding!
]]>Permit me to rant a moment. There are those who see our companion animals as things. Too stupid to know any better, to remember their past, to understand pain and loss. Then there are those who know better. Not because of some idiotic mystical nonsense, but because they’ve actually opened up their hearts and minds to a dog, a cat, or some other intelligent animal. That’s when they learned that, while no animals – a cat for example – are quite as smart as a human they’re damn sure not stupid. The smarter ones are … smarter. They remember things. They get sad and even vindictive. If you don’t think a cat can hold a grudge and then make a very clear point beyond “stupid animal” about it, you’re the one who is fooling yourself, not the cat owners.
The same goes for a dog. Hell even pig owners who’ve allowed a pig the same special place in their family as a cat or a dog can see an impressive amount of self-aware “person” in that creature. It’s a shame they’re so tasty I’m not a PETA member, I’m an omnivore, but I believe in treating all animals (even the ones we eat) with respect.
I address this post to those insensitive, vulgarly stupid assholes who close their eyes to reality and favor “conventional wisdom” – for whatever reason – about just what defines a “person” and whether a cat, dog, pig, horse, dolphin, chimpanzee, or whatever has a right to be treated, respected, and loved like a person.
For those of you who would tell me, in my current situation with a sick cat whom I’ve lived with and loved deeply for my entire adult life, that “she’s just a cat” and that I’m somehow being unreasonable with the depth of emotion I feel over her rapid decline and eventual loss, I have a few things to say to you.
First: Fuck you. Seriously.
Second: I feel very sorry for you (but still, fuck you) because you’re missing out on one of the most important lessons you can learn in this life.
Third: I never wish a beloved animal (*person*) in your life to die, but here’s what I do wish upon you: Against your will, a creature whose intelligence and personality you’ve dismissed, will worm his or her way into your heart. You’ll grow to truly recognize them for individual they are. Then you’ll be forced to be there for them when they age and eventually die. I hope that by this time your bond is so close, you wouldn’t dream of being impersonal … that you’d feel the responsibility toward your loved one that really is there – the deep-seeded need to be there for them, to make them comfortable, to worry over whether to let them go naturally or worse, to worry over when it’s time to end their lives for them.
In short: I wish you my fate. Not out of cruelty, but out of a hope that there’ll be one less hard-headed, closed-minded, soulless fuckwad out there because he or she went through a heart-breaking experience that taught them one fuck of a valuable lesson about love and commitment.
Even if it is “just a cat.”
]]>On November 2, I gave a whirlwind tour of Xcode 4 (highlights from my Xcode book) to the nice folks at the DC CocoaHeads meetup. Side note: LivingSocial has a great office space.
I was also a guest on episodes 34 (November 21), and 35 (November 28) of the iDeveloper Live podcast. The hosts, Steve “Scotty” Scott and John Fox – graciously allowed me to blather on about (you guessed it) Xcode 4. Episode 34 was about its good side; episode 35 was a gripe-fest. I felt rather bad about spending nearly an hour complaining about a tool that is rather good, in spite of its faults. All month long, Scotty had been giving away e-book copies of Mastering Xcode 4.
Thanks to my hosts for the opportunity to speak and thanks to all those who listened patiently to my dimwitted jokes. 
* I also just discovered Google Scholar.
I haven’t posted in awhile (especially anything Cocoa related) but the subject showed up on my radar again. What bothers me is this generalization: if you’re not (always) segregating your windows with nibs, you’re (always) doing it wrong. I have to take a stand. Blind adherence to generalizations will get you in trouble.
Let’s consider the approach. The basic idea is that every window in your app is placed into its own Interface Builder (nib) file. This coincidentally forces you to use one NSWindowController per window, which in turn forces you to keep that window’s UI management logic separate from other windows’ UI management and so on. For larger applications (which implies larger Xcode projects) this has performance and organizational benefits.
Note the term “basic idea” – this is where rote advice repeaters can fail their listeners. I’ll admit it: I make this mistake myself. If you repeat a bit of advice often enough, you become lazy. You carelessly overgeneralize. This can result in misguiding others. We’ll get to that part in a bit. For now, let’s have a bit more detail.
If you’re not familiar with the concept of “lazy loading” you’re doing yourself and your users a disservice. Lazy loading means only loading resources when the user’s actions demand the resource. That is, only load the UI that’s needed now. In the case of the “monolithic nib” – where the entirety of your application’s UI is in a single nib file – your application takes longer to launch and uses more memory whether it needs to or not because it’s loading everything. This is often unnecessary.
A favorite example is the preferences window. A user is unlikely to adjust the application’s preferences every time they use the application. It just doesn’t happen and we know this. Many apps have toolbar-driven, multi-pane preferences windows (another “is-it-really-necessary” discussion begging to be written). Does all that need to be loaded at launch time? No. It’s better that the preferences UI be loaded only when the user requests it for the first time.
Another example is the really complex application. Complex panels, such as Xcode’s Utility Area, can come with entire populations of sub-panels and may never be used during a session. If you’re any kind of sane, there’s at least one top-level NSViewController that manages such a panel but in reality, an extremely complex application may have view controllers for each sub-panel as well. For something as large and complex as Xcode, it’s a good idea not to load all of this unless the user asks for it.
All but the smallest, simplest of apps usually have at least one opportunity for lazy UI loading of a unit. The agreed-upon major unit is a window and its contents; a view is the minor unit. Anywhere you see a UI unit that may not be seen during a user’s session is an excellent opportunity to segregate and therefore to save time, memory, and even battery power. iPhone users will thank you for the latter.
In fact I’ll go a step further by saying anywhere you see an NSWindow and NSWindowController pair or an NSView and NSViewController pair that may not be used is an opportunity to optimize.
An opportunity. Remember the specificity of that word.
From the developer’s perspective, simply maintaining a large Xcode project offers its own set of challenges.
Good organization is more than just satisfying OCD. A well-organized project makes it easier to find things months or years down the road when you revisit a part of your app you haven’t needed to in awhile. Believe me, this long-time-no-see scenario happens often when you have more than one app. Or when your app is complex. Or when you’ve come back from vacation. Or when you finally got over being sick to death of even looking at that damn app.
Organization is especially important when working on a team or when you pass on the torch to another developer. This is similar to the need for readable, well-commented code. You can’t remain intimately familiar with every facet of your large project. Your future self (or your replacement) will thank you for making things easy to parse later.
Putting the preferences window in PreferencesWindow.xib (or whatever clear and concise naming convention you choose) makes it easy to find the related UI. Together with groups (the yellow folders in Xcode), the project is more easily navigable. You have a reasonable minimum of three files to maintain: PreferencesWindowController.h, PreferencesWindowController.m, and PreferencesWindow.xib. Put these in a group called “Preferences” and you can keep the group collapsed until you need to work on the preferences system. Put other preferences-specific source files there (like view/view-controller files if it gets really complicated) and you stay organized.
Zen and the Art of Xcode Project Organization.
Another organizational benefit is fault tolerance. Although it’s a less frequent occurrence these days, corrupted nibs have bitten nearly every Cocoa developer. Like the segmented hulls of modern ships, the puncturing of one segment shouldn’t sink the ship. Similarly, one corrupted nib in a well-segregated project causes less of a mess than that monolithic nib into which you stuffed the entire universe.
This is much less of an issue if you’re using a source code management system like Git or Subversion and make frequent, task-oriented commits. You are using source code management, aren’t you? Even so, there’s still risk of unnecessary loss of work if a nib is corrupted when you’re changing a lot of your UI at once. In the monolithic nib, all those changes are gone if the nib croaks; with multiple nibs, you only lose the work done in the corrupted nib. It’s a marginal benefit but you’ll be glad for it if the situation rears its ugly head.
The point I’ve been coming to is this: it’s possible to take it all too far.
Consider a small utility app. It has one main window that’s always visible and a secondary window (let’s say a floating palette, despite their decreasing popularity). Neither window is particularly complex and the secondary window is likely to be invoked during each (possibly every) session. The use of multiple nibs here is ridiculous. I’ll tell you why.
The user launches the app to perform a task. The MainMenu.xib file is read and the UI is loaded. The task likely involves a utility palette. The app is user-friendly so the palette remembers its shown-or-not-shown state from the last session and needs to be loaded. Now there’s a second round-trip to the disk to read its nib file and load its UI.
If you know the utility application will never become the next Photoshop, your blind “future-proofing” is utterly pointless. You’ve increased your application’s load time and disk activity for nothing. You followed the “conventional wisdom” you heard summarized somewhere without considering why you were doing it and in this case it was the wrong thing to do.
You’ve also added more files to your Xcode project. Did it help? Did it make your small, simple project easier to navigate and to maintain? I’ll bet not. Interface builder helps you extract and segregate UI from a single nib; you’re on your own if you want to merge nibs. From an organizational standpoint, over-segregation can be a burden. Just navigating between several interrelated nib files can become cumbersome. It now involves tabs and assistants. It may soon involve satellite surveillance and an operations team. Think The Bourne Identity.
Is it all really necessary? For medium-to-large-complexity apps, you’re sure to benefit at least a little. For small projects, you might be hurting performance and maintainability. Remember the word “opportunity”? It’s not the same as “requirement”. Always consider the units of measurement (window/controller pairs and view/view-controller pairs) and the likelihood those units will be used in each session.
In short: prefer true wisdom to conventional wisdom and think before you segregate.
]]>
A rather nice e-mail arrived in my Inbox this morning from a gentleman who used my Ziplight Spotlight plugin well past its prime. “Chris” writes:
…I noticed you’re the ziplight developer, so I just wanted to thank you for it, and share my story; since I suspect I’m the only man who used Ziplight on Snow Leopard.
I was searching for a solution to tagging comic files (just renamed zips) without using spotlight comments, and then I thought of a slightly ghetto method using file names. So I took ziplight and swapped in the UTI I needed.
Since I was a late comer to Lion, that act got me an extra 2 years of life out of Ziplight.
It makes me happy to see someone still had a use for it well after it became unnecessary. Old apps and plugins so often fade quietly into history…
]]>My sister lost her (very sweet) cat to cancer. My own cat had a lump that was removed – she’ll be fine (but she is an old lady and still has old lady issues). The problems didn’t stop at pets, though.
One of my sisters has been diagnosed with Multiple Sclerosis. She’s a mother of two in her thirties. It’s not mild but fortunately it’s not end-stage-severe. We’re all still reeling. Just a few months ago, her youngest daughter had a seizure . Looking back, it’d been going on awhile but this one was bad. She’s now on medication, probably until her adult years.
Another sister (mother of three) was very likely misdiagnosed with MS a few years ago but her latest doctor – who is angry at the previous “diagnosis” – is now thinking syringomyelia but a lot more testing is necessary. There are definitely cysts on her spine (thus the earlier diagnosis) and the kinds of problems that go with them. We’re still waiting to know more.
As if this wasn’t enough the sister I just mentioned has a fourteen-year-old son. He’d been having odd problems for quite some time now. I’ll skip the details, but it’s now confirmed: he has a form of lymphatic cancer. He’ll have a catheter inserted tomorrow so he can begin chemotherapy. At 14. Fortunately, this form has an 80% recovery chance (which I think is higher since he’s so young and it was caught so early).
But wait, there’s more. An uncle on my father’s side was just diagnosed with prostate cancer. It has progressed enough that it’s now in his bones. I don’t know much more than that.
A familiar problem we thought we’d solved popped up as well – Matt’s ongoing sleeping problems have resurfaced with a vengeance and it looks like it’s back to obstructive sleep apnea (for which he’d previously had a positive sleep study and painful operation to correct). We’re exploring next steps but for now, it’s back to the problems associated with lack of oxygen while sleeping many times per night.
How are we taking this all? Well, we’re all alternating between grieving and laughing together. It’s our way. I’m personally bouncing between optimistic and focused (throwing my energy into work) and depressed and crying. It’s a lot to deal with but that’s what’s going on with me right now.
Keep me in your thoughts and prayers (just because I’m areligious doesn’t mean I don’t appreciate the latter). A special thanks to those of you who’ve sent me words of support over the last few weeks as some of this came to light. Truly: thank you.
]]>From that moment forward, I kicked my hobbyist-level programing dalliances into high gear to become, a decade later, a damn good Cocoa developer 100% devoted to the Apple ecosystem. 100% of my income is due to my Cocoa and Xcode knowledge and I’m much happier than I was as a network engineer – even as IT Manager.
Steve Jobs started something. Then he was booted out of it. It suffered. He came back. In less than 15 years, it rocketed to the top of many lists that matter. Steve’s leadership made my career and success possible. Would I have found it otherwise? Possibly – I’m a very driven person – but “possibly” didn’t happen. Steve and Apple did. So I am where I am now because of it.
Thanks, Steve, for positively affecting my life.
]]>As a thirty-something, I am really starting to enjoy the confidence that comes with learning my twenty-something self was overconfident. An odd paradox, to be sure. This is a normal state for one’s teens and twenties and nothing to be ashamed of. Not outgrowing it by forty … that’d be squarely into shame territory.
In Reason number 7, Stephanie writes:
You see an ex from a number of years ago. Despite the fact that you are now on good terms — friendly terms, even — the relationship ended somewhat badly, and you recognize that most of this is your fault. In your inebriated state, you apologize, profusely, for your past behavior. In your mind this amounts to a sort of self-deprecating wisdom, an acknowledgement of past wrongs and a mature desire to right them. In actuality it is the manifestation of the desire to have everyone like you, despite the fact that you have, undoubtedly, fucked some people over in your life. Additionally, approaching an ex in a state normally reserved for hitting on people and then invoking your relationship comes off like, well, hitting on them. They will probably also not want to remember how you fucked them over. They will have overcome this and constructed an idea of who you are w/r/t you fucking them over, and used this to move on. You are not helping yourself. It is time to go home.
The emphasis is mine and it’s what I want to discuss.
The older I get, the more willing I am to acknowledge stupid shit I’ve said or done to others in the past. In part, I suspect it’s easier to own up to because it’s more distant. I like to think, though, that it’s also maturity and recognizing that, even as a twenty-something adult, I view myself ten years ago as a kid with adult rights and still very little by way of a clue. I also realized in my late twenties that I have the same sort of social problems described by Asperger’s Syndrome, though I’ve not been diagnosed with this. I worked hard to learn to recognize those problems and work on them. I wish I could say I’ve eliminated them, but I haven’t – they’re still there and I’ll likely have to work at it all my life. But it’s getting easier with age. Introspection is getting easier with age.
So. Is the desire for atonement really a “manifestation of the desire to have everyone like you”? If yes, how much? Completely? Half and half? Just a little bit? More to the point, is that actually wrong? Of course ”normal people” desire that everyone likes them. They may acknowledge that it’s not a realistic desire in practice, but we’re hardwired social creatures by nature. Surely it’s not wrong to desire that everyone likes us, so long as we know it’s never going to happen. Isn’t that desire part of the mechanism that prompts (most of) us not to be sociopaths?
So what do you think? Ignoring that it’s a reason for leaving a party, is Stephanie’s (seeming) all-or-nothing label for the compulsion she describes mature introspection, or the oft-scorned desire for everyone to like you? Moreover, is the latter so black and white (and “bad” or “immature”) as people make it seem?
To Stephanie if you read this: You make good points, which is why I chose to read more. Please don’t think I’m singling you out or chastising. Also, please like me. 
First, I’ll admit my own misunderstanding lead to some disappointment before the device even arrived. Based on the wording, the device’s iOS-app-controlled nature, the look of its lens, and of course the price tag, I had assumed a fully “remote controlled” camera. That is, a camera whose position you can control, letting you pan and perhaps zoom. Other (cheaper) products do this, albeit with web-hosted software. It turns out this is not the case. This camera swivels on a magnetic base. By hand. No remote-controlled panning. Damn. My mistake, I should’ve read more carefully (though the product site offers surprisingly little detail).
Second, their claim of “wireless” is outright false. The device requires a USB cable (with AC adaptor for wall sockets) for power. Only its data is sent wirelessly using your WiFi network. I had assumed it could be battery powered (and hoped for reasonable battery length). Nope. No battery option. It would have been nice to place the device up high in our main living space without a wire dangling down. Nicer still would be to have it last at least an overnight trip. Not the case. Requiring a wire for power is not wireless. This company is extraordinarily bad at communicating their product’s capabilities. Or they’re intentionally misleading customers.
The problems began the moment I opened the box. I began pulling the device (and its wireless wires) out and removing the twisty ties, additional wrappings, etc. The USB cable (two, actually; the second, short cable is of unknown intent) was “protectively wrapped” at both ends. I’m used to cast plastic caps or shrink-wrap cellophane sleeves. What I wasn’t expecting was cellphone tape directly applied to the cable ends. You read that right: the cable ends were very securely wrapped with plain old cellophane tape. Tape that had to be cut and pried with fingernails. Tape that did not come off in one piece. Tape that’s still partially stuck to both ends of each cable.
So I plugged in my wireless camera’s wire. Its light lit. I was at a loss as to what to do next. I dug around and found their tiny “Quick Start” guide. After the obligatory “plug in your wireless camera” steps, it informed me I had to download their app from the App Store. Oh, right. Makes sense. Maybe a brightly-colored reminder card on top of all that packaging somewhere would’ve reduced the WTF factor there, but fine. My mistake.
I looked up the app – Stem:Connect – and paused a moment in worry. At the time, there were 115 reviews and the app averaged 2 out of 5 stars. Uh oh. I installed and launched it. It crashed. I launched it again and followed its prompts through creating an account with Stem’s network. I did read that the camera depends on their service (worrisome, but I hoped there’d be an alternative in there somewhere – a hope that died today) so I wasn’t surprised. I waited a moment for their confirmation e-mail with my activation code and typed it into my iPhone.
The next step was to set up the device itself. This involved switching my iPhone to the device’s wireless network, entering my own network’s credentials, then switching the phone back. After a few false starts (the app wouldn’t connect to the camera for a full minute), I started to see the camera’s image updating.
Were this a movie, I’d have demanded my money back in the first five minutes. While the five-second live video lag is understandable, the interface’s lag is not. Every UI action is delayed. Some delays make it feel like it’s about to crash.
Even less understandable is the user interface. Stem:Connect is apparently meant to be a one-stop shop for all of Stem’s products. As far as I can tell, there are two and they have nothing to do with one-another. Unless you own all of Stems products – and very shortly I will happily be back to owning none of them – much of the room taken up for navigation is wasted space. For someone who just wants to check up on their home, a dedicated app makes a lot of sense. As it currently exists, I have to launch the app, select the type of device (the camera), then select the device itself. Every time. Bewildering.
You cannot rotate the device to see the input in its proper aspect ratio, which means the video is much smaller than you’d expect, as it’s stuffed into “portrait” orientation. In the main living space of my home, things on the opposite side of the room are small and indistinct. Worse than that, the camera’s image quality is poor in lower light situations. A cheap US $20 USB web cam I found on Amazon looks positively beautiful in average room lighting conditions compared to the iZON.
A few weeks ago, the East Coast was rocked by surprise earthquake. My house wobbled. A rather unexpected event for this region of the world. I don’t think the iZON would’ve noticed. Its motion detection requires a bit of setup (it’s not a simple “on” switch at first, though you wouldn’t know it from the UI). You turn the feature on then set up its sensitivity and “active area” (the area of the image you want to monitor). Although I turned on push notifications when the app (successfully) launched, and even verified it was allowed for Stem:Connect via the iPhone’s settings, but I could not get this to work.
I designated the whole damn image as the active area, set the sensitivity all the way up (and down, in case I misunderstood the direction) and acted a fool waving and moving around. No luck. I moved closer, moved further. I even waved my hand (quickly and slowly) directly in front of the lens, thinking that would surely count as motion.
Nothing.
Motion detection is the primary reason I want a remotely-accessible camera. I want to know if someone’s there. If they are, I want a picture of them. Or a video. Maybe even their voices (so the audio streaming is a nice touch). The iZON, however, doesn’t seem particularly motivated to give a damn.
Too goddamn bad. There’s no off switch. There’s no “pause” switch. The only mode that’s truly wireless is its “off” mode because you have to yank the power cord to turn off the device. Otherwise, your house is under 24-hour video and audio surveillance (routed through Stem’s systems). Oh, and your bandwidth? Yeah, it’ll be using that too.
What an awful, ill-conceived, overpriced failure of a product launch. Seriously.
]]>
I predict a new technology that actually lets you store your own data on your own local network. Imagine! You keep your stuff in your own home or business! Fully Cloud-compatible (via backup and sync services), your stuff is still accessible without the Internet! What do I call this down-to-Earth Cloud-based technology? I shall call it … the Fog.
The Fog is an at-home or in-business successor to Cloud-based technology. It’s like a local area network … but with a better name.
]]>
If you only know about me because of the Xcode 4 book, you might not be familiar with my “usual” style of writing. That is, irreverent, quirky, off-color, etc. It may surprise you to know I’ve always loved creative writing; I’ve just never “put myself out there” beyond my blog. Well I self-published an adult-humor short story on Kindle Direct Publishing.
I Like to Write is a doltish name, isn’t it? It’s a tale of an elderly, mentally unstable woman stalking an elderly man of failing health by writing him lots of letters. Nancy likes to write. She really likes to write. The trouble is, both her simple language and her seemingly innocent infatuation with Fred is less charming and more scary. This tongue-in-cheek tale is told through the eyes of a young man who’d just moved into the apartment complex. This short story is $0.99 through your favorite Kindle reader. I hope you enjoy it.
]]>
Well that’s that. The Xcode 4 book is finished and currently being printed (and prepared for digital sale in a number of formats as well). You can preorder it now if you like. See the official announcement for (un)specific dates.
Special thanks to the crew at Peachpit (Cliff, Myrna, Scout, Robyn, Kim, and the design team I didn’t get a chance to work with directly). Thanks to all my friends and colleagues for their support and to Matt for putting up with the whole thing. Thanks to Cyril and Colin for allowing me to use their work while writing the book. Finally, thanks to Duncan for getting me in touch with Cliff.
]]>In summary: I’m a coding whore, not a coding slut, thank you very much.
]]>
The Recessed Look in Dictionary.app
The effect I’m talking about is shown to the right. When you search for a word and there are multiple results, you get a list on the left that looks as if it’s recessed. It’s no simple shadow edge because, to achieve the desired visual effect, the top and bottom have to fade out, forming a visual depression.
This lovely effect requires subclassing three views (as far as I could tell to get it to work correctly). A NSTableView subclass provides the basic shadow edge. An NSView subclass provides the same edge but a fade at the top and bottom. An NSSplitView (set to Thin Divider mode) subclass draws the divider with the magic slightly-lighter-than-default color and the same top and bottom fade.
The “backing” view (the NSView subclass) has to provide the fade because the table view’s top and bottom edge move around when scrolled, which would take the fade with it were it responsible for this. The table view is sized in the backing view to leave an 11-pixel gap at the top and bottom to let the backing view’s fade show through. The backing view stays put and also provides a repeat of the shadow effect to account for the iOS-like elastic scrolling that was added in Lion. Since table views are happiest when they draw a background, this was a good design compromise.
It could be better. It doesn’t exactly match Apple’s flavor as I’ve fudged some things and don’t have enough time to polish it up more. You’re more than welcome to fork it on Github, make improvements, and send me a pull request.
See the source page for details. Long story short: copy the three view subclasses (six source files in all) into your project. Open the example app’s MainMenu.xib and copy the split view and its contents into your project (you’ll probably want to replace the web view with something sensible). That’s all there is to it.
I use and rely on xScope (by Icon Factory) for such things. Well worth the money over the years.
Either the source page on my site or from Github. Liberal license (but I request attribution … you know … ego whoring and all). Enjoy!
]]>
Yesterday I received a robo-dialer call from American Red Cross. Their robot expressed a craving for my tasty, tasty type O blood – a case of mistaken identity. It gave me several menu options but none of them were “leave me the hell alone.” I sighed heavily and gave up for the evening. This morning Matt mentioned a news article talking about a district judge who okays civil suits against robo-dialing. “Oh yeah!” I yelled, flashing from relaxing morning coffee mode to angry afternoon mode in an instant, then I ran to my computer to begin my crusade anew.
You see, being a non-profit organization, American Red Cross doesn’t have to obey the Do Not Call list. Fuckers. My only hope, the Internet claimed, was to contact them a million different ways and keep trying to be removed. Apparently that’s the hard part. Not only is it difficult to find any way to talk to a person who can actually help with this, but they really seem to be disinclined to give a shit.
Unless, of course, you inform them you have “undesirable blood.”
Random strangers in forums as well as people I know told me the quickest way to ensure the Red Cross wouldn’t touch your blood with a ten-foot blood-extraction device is to tell them you have some sort of disease or are a “man who has sex with men” (apparently “gay” isn’t politically correct in this particular context). Armed with this information, I sent them a letter, which I present below for your enjoyment.
To Whom it May Concern:
I’m writing to ask you to remove my (newly-acquired) telephone number from your robo-dialer. The number is XXX-XXX-XXXX.
Trouble is, I don’t have the blood type your robot stated it so desperately craves. If I did, you wouldn’t want it anyway, as it’s riddled with disease from my crack-addled, homosexual, alcoholic, prostitute boy-toy with whom I share needles and dirty, dirty bareback butt-sex in public truck stops.
Also, while I love pricks – can’t get enough of the devilish things, in fact – I’m outright terrified of needles. Well, needles without illegal drugs in them, at any rate.
On the other hand, if you have a handsome, boyish vampire (the modern, caring kind they show on TV these days), I might reconsider. I wouldn’t mind that particular form of blood extraction and, like a wistful teenage girl, I’m CERTAIN I can change him …
Sincerely,
- Joshua Nozzi
This isn’t to suggest I dislike the American Red Cross. My most recent donation was intended for the Japan relief fund. I just don’t like people (or bloodthirsty robots) calling me at random, asking for my body fluids.
]]>Apparently, for a four-hour window this past Sunday, any user account could be accessed using any password. Because a user’s files are encrypted on Dropbox’s servers (not on your computers or mobile devices), this means a security screw-up like this can give unimpeded access to any user’s files.
Conversely, had they chosen to encrypt files client-side, this authentication bug would not have granted access to the files because the password / decryption key would not match and the files would come back scrambled if they came back at all.
Twice, Dropbox has demonstrated poor security practice. Some would argue they also demonstrated dishonesty by claiming their employees couldn’t access the files (their wording suggested “unable” rather than “not allowed”). Now a new problem has been demonstrated: they have poor or nonexistent testing practices when rolling out updates to their servers. Had they at least automated testing of their authentication system, they would’ve discovered the problem before ever having deployed the changes to their public-facing servers. As a user, I have yet to learn of a single one of these incidents from Dropbox themselves.
This latest sin and all it reveals has caused me to abandon Dropbox entirely. I can no longer trust them. Wired suggested two alternative services: Wuala and SpiderOak. Both offer client-side encryption and Mac and iOS clients (important to me). I’m currently leaning toward Wuala (see update below) but have learned to do my homework first. I won’t be signing up for another Dropbox-like provider, free or not.
It’s that last sentence that could be used as a retort: “Relax, it’s a free service.” Granted if you need 2 GB or less, the service is completely free. Nice of them but not nice enough to allow them to – in my opinion – mislead me about their security and for me to put up with repeated ham-headed security offenses. Those who’ve known me awhile (or at least followed me on Twitter) likely remember I was hesitant to use something like Dropbox for awhile at all. I begrudgingly tried it and changed my opinion. I found a few good uses for it. Not good enough to make me want to integrate my own applications with it (a popular request a year or two ago), but good enough to use on its own.
I’m of the opinion that Apple’s upcoming iCloud service will offer a seamless file syncing experience (hopefully more “seamless” than iDisk). I also believe they’ll worry over security as well – they do have a reasonable track record. As I use all Apple devices, I should have no trouble getting to the stuff I need … with style. For this reason, I’ll be using Wuala (or SpiderOak) as a stopgap until iCloud is available.
So long, Dropbox, and thanks for all the fish.
Update – Err, never mind about Wuala. It’s Java-based (I’m a “native app purist”) and decidedly not user friendly. I can’t figure out whether it offers automatic syncing at all and it appears to be still in beta. Further, its completely unexplained “file system integration” setting in preferences is enabled but its “check” says it can’t “Access Root Directory” to offer this feature. No fucking thanks.
]]>There are two main scenarios in which you frequently fail hard, resulting in my assumption that you are a semi-professional entry-level developer at best. This makes me hate you. Often, it makes me fire off an angry rant to your contact address, chiding your lack of experience and your complete destruction of my faith in your site’s ability to be useful to me, even if I could find my way around your stupidity. Let’s explore these scenarios together that you might learn from them.
First, you assume based on my using “Mobile Safari” that I need to be railroaded to your “mobile version.” Many of you don’t even ask – you just shunt me to mobile and maybe, if I’m lucky, you give me the opportunity to view the “full site.” How generous. Some of you douche bags then fail to persist this choice so I have to go through the whole thing again the next time I visit (hint: there likely won’t be a next time). Then there are the rest of you. The assholes. The ones who classify visitors as “normal” or “mobile” and shove the “mobiles” bodily toward the “mobile version” without a choice.
I hate you. I hate you so much.
That might be alright for other mobile browsers (because they truly do suck), but not for my iOS device. I paid good money for great standards-compliant mobile browsing capabilities. Why the hell would you take that away from me for the simple crime of visiting your web site? Unless your site requires Flash (and it better fucking not), or mouse-overs (which is not compatible with our modern, growing, touch-based world), you have no reason whatsoever to force an iOS device to a “mobile version.” If I wanted some shitty, Y2K telephone web browsing experience, I’d shell out $500/month for 1.5 MB of download capacity for a Motorola RazR and download a low-fidelity Who Let the Dogs Out ring tone for $5.00.
I digress. If you must provide a mobile version in 2011, ask me up front if I want it and remember what I told you. A great mobile browsing experience on an iOS device has been available to users since 2007. You’ve had plenty of time to learn this so knock it the hell off.
The other scenario involves “clever” JavaScript that decides either my whole web browser is “unsupported” (and refuses to let me in) or that I don’t have some plugin (that I often do) and doesn’t even try to do the right thing. This is just as idiotic as the “mobile version” scenario. These so-called web developers decide Safari (as a common example), which is standards-compliant and scores extremely high in this regard, just doesn’t work right and they won’t let you in if you’re using it. So many online banks did this until very recently (now only a few do it) for reasons completely unknown. Some of you assholes even go so far as to display a cheeky “get a real browser, LOLZ” message to users.
If you do this, what you’re really telling me is you’re completely incompetent as a web developer and I should be very wary of your site anyway because you clearly don’t know what you’re doing. If your site “doesn’t support” a modern, standards-compliant browser it’s your fault, not mine. It’s a bug and a goddamn big one. What you’re saying is “I’m a fuck-up, a miserable failure, and my site probably sucks even on my own browser of choice.” You’re showing the world that you (and the company that hired you) are unprofessional, condescending jackasses who don’t deserve my business or readership because you’re either too lazy or too uninformed to build a proper web site. You tell me to get a real browser and I imagine you’re a high school aged relative of some clueless business owner who “wanted a web.” This isn’t the 1990s, folks. Hasn’t been for over a decade. Just having a web site – even a shitty one – won’t make you rich. These days it’ll just make you look like a moron.
So the real message isn’t “get a real browser” but rather “build a real goddamn web site.” It doesn’t have to be fancy. It just has to look nice and work no matter who visits it.
The other side of this is specific capability detection. You decide to employ your own “do they have Flash” routine. Ignoring the folly of reinventing the wheel many, many times (and doing it poorly almost every single time), it’s bad enough many of you decide to restrict capabilities rather than trying anyway and letting the user know “this may not work.”
These types of warnings should be informational. You should never ever restrict things on purpose based on your “clever” little JavaScript hack. Your goal should be to inform the user something seems like it may not work but try it anyway. To simply avoid trying to load a plugin because your detection mechanism failed to detect it will almost always end up mistakenly restricting a user. Real web developers’ sites degrade gracefully. They don’t fall flat on their faces, pissing and shitting themselves because their capability detection code (which often is never updated as browsers grow) was mistaken. It’s the same mindset as “Oh god, a big black man! He’s going to rob us!” It’s prejudice born of ignorance. Plain and simple.
If you do this you’re an inexperienced developer (and possibly racist). You may be an excellent graphic designer but you’re a shitty developer. Your goal should be standards compliance and graceful degradation (which is part of standards compliance but bad developers don’t seem to understand this), not trying to second-guess every possible scenario for every version of every browser. If you’re doing the latter, you’re doing it wrong and you’re pissing me off.
Okay, now that I’ve gotten that off my chest, here’s a message of hope: companies are beginning to realize how foolish it is to cut off entire browsers and platforms, and that there’s just no excuse for it these days. They see other companies’ sites – full, rich web applications – working just fine on all modern browsers. Hopefully this is sufficient pressure to force old-school (and newbie) developers to learn the modern state of the craft properly – to bring them out of the protective shell of their browser of choice and realize they must support all browsers. Cutting off a whole browser because [ pretty but useless effect ] isn’t supported is idiotic and detrimental to the goal of a web site: to draw in and retain repeat visitors.
Don’t be a douche bag web developer. You’ve got no excuse for it.
]]>One of my pet projects started growing and growing. It was a soft, melodic orchestral thing with a lot of emotion. Each time I’d write a few new bars, I’d play it back and know it had potential. Then life intervened. I touched it a few times since then but never in any depth. During my two-week vacation before starting my new job, I decided it was time to dust it off, polish it up, and put it out there for the world. I call it by its first name: Cycliss.
I love this song. I hope you like it too.
(Headphones recommended.)
]]>
The Monkey Tail Beard (not mine)
I’m speechless. This is apparently a real trend. It’s as if someone said “hey, let’s take something a ridiculous as the green-dyed mohawk and give it a twist of gentlemanliness.”
No, that is not me in the photo.
]]>