I forgot how much I hated Windows Mobile.
Wow.
Reply
Color me impressed.
I just got a DS409+ from Synology. What a perfect little unit for a small business!
The upshot of this is that for about $1500 you can have a 6TB RAID-5 box which allows you to run a small local web site (and runs PHP, so you can install a blog or wiki), allows you to create a shared file system which can be controlled using group permissions (so common shared files can be shared in the office), and have plenty of space to use it as a Time Machine server. It also will run an e-mail server, and you can even set it up to use DDNS.
I definitely will be getting one of these if I ever open a development office, so we can share common development tools and have a way to back up the office.
Naturally, of course, I probably could have hand-built all of this for less in a cheap Linux box. But the beauty of this is that it’s a self-contained and quiet little box that’s relatively easy to set up. This little guy is going into the basement so I can back up my my laptop, desktop, and my wife’s desktop machines.
210°
It appears to be H in HSV space for Apple’s standard color.
I thought 210° was just the magic number for iPhone software: the gray-blue color that appears throughout the UI is variations of H=210°. But it also appears that the Apple Mail application uses the same light blue-gray color for the side panel, and for other side panels elsewhere.
As an aside, the blue throughout this blog is at 205°.
As a second aside, for those who don’t know what I’m talking about, here’s the algorithm to convert from HSV to RGB, along with the formulas to go the other way around: Wikipedia: HSL and HSV
Of course it’s important to remember to honor the user’s color selection when building custom controls: NSColor’s +selectedTextBackgroundColor returns the hilite color, and +selectedControlColor returns the color for the face of a selected control, such as the color of a menu item highlight.
New Theme
I’m not quite sure I’m happy with it. But it’s better than the plain Jane theme I was using before. Borrowed from wordpressthemesbase.com.
Tempests in Teapots.
At work an interesting tempest in a teapot arose.
And in my personal hacking life, another tempest in a teapot.
The former I cannot discuss. The latter, however, I can: my little protest in code has come to bite me on the ass. Or rather, more specifically, it has come to bite another poor fellow on the ass: I just found out his application has been rejected because Apple believes FlowCover is CoverFlow, despite the differing graphical appearances. (Specifically my tiles don’t “pop” the way iPhone CoverFlow tiles do as they pass through the center. It was a style choice.)
I’ll wait if he wants to raise hell publicly; it’s not my story. But I do know there are at least two other applications currently on the Apple Store which successfully shipped using FlowCover, so it just illustrates the lack of standards on Apple’s editorial review process.
And it should be evidence that the App Store is succeeding because of the success of the iPhone, and not the other way around–as Verizon, T-Mobile, Google and others seem to believe as they shove their own mobile device application stores down people’s throats.
Apparently the folks running the various MNOs are idiots.
Verizon Drafts Developers Into Mobile Software War on Apple
The companies appear to be responding to Apple, which announced this morning that its iPhone App Store, now only one year old, has surpassed 1.5 billion downloads and is serving 65,000 applications.
“The App Store is like nothing the industry has ever seen before in both scale and quality,” Apple CEO Steve Jobs said in a press release. “With 1.5 billion apps downloaded, it is going to be very hard for others to catch up.”
Though press releases are inherently boastful, Jobs is correct that Apple is well ahead of its competitors in the mobile software space. The company launched its application store in July 2008 with the release of the iPhone 3G. The App Store’s consumer friendly interface, which makes purchasing and downloading applications as easy as downloading songs in the iTunes Store, is benefiting software developers, some of whom have become rich thanks to explosive sales of their apps.
I can almost hear Steve Jobs cackle in his private office, realizing how badly the MNOs and MVNOs have missed the mark.
It’s because they all assume that the iPhone is a phenomenal success because of the App Store, when the reality is that the iPhone has succeeded despite the App Store.
And of course Steve Jobs continuing to remind the fellows at Verizon about the App Store completely diverts their attention from what made the iPhone a successful platform: usability, usability, usability.
What’s particularly amazing to me is that most application stores are not useable in the least. Apple’s App Store famously requires an editorial review before an application can be posted, which has resulted in rejected applications because of on-line content. They demand 30% for distribution. And there is the famous “drive to 0” in the price point, combined with top sellers being fart applications and things like “Pocket God” (great game, but not an intellectually expansive selection) which have prevented more expensive and interesting vertical market applications from appearing. And the on-phone App Store experience is, at best, useable: if you know the name of the application you’re looking for you can search for it, but the small screen means you’ll only see 7 applications out of 65,000 at a time.
So now Verizon is going to (a) piss off the developers who are used to being able to control the relationship with their clients (a valid criticism of the App Store: I cannot ship a demo which requires registration), (b) make it harder for developers to push their product (another criticism, given that in order for a user to by my iPhone app I have to pass control to Apple, losing control of the experience and potentially handing a sale to a competitor), and (c) get charged 30% for the privilege–and for what?
The iPhone App Store succeeds because the iPhone is succeeding–and the iPhone’s initial launch was a successful launch despite the App Store, which didn’t even exist during the first year of the iPhone.
Fixed a bug in the asn.1 library
Actually, it’s not my fault. I got the following message from Al Jeyapal, pointing out the error of my ways.
From: Al Jeyapal
To: woody@chaosinmotion.com
Date: Tue, 14 Jul 2009 14:29:36 +1000
Subject: BerUTC Parsing in ASN.1 Library
G'day mate,
I'm not sure if you're still maintaining the code for this library, but
thought I'd send this through in case you are. There is a slight problem
with how BerUTCTime nodes are created. The SimpleDateFormat needs to have
it's time zone set explicitly to UTC, else it will interpret the date using
the time zone from the current locale.
Diff is as follows:
@@ -40,6 +40,7 @@
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
+import java.util.TimeZone;
/**
* Represents a UTC time object.
@@ -98,6 +99,7 @@
{
if (gFormat == null) {
gFormat = new SimpleDateFormat("yyMMddHHmmss");
+ gFormat.setTimeZone(TimeZone.getTimeZone("UTC"));
}
}
Cheers,
Al
Fixed in the current build.
Thanks!
Of course I feel stupid: I never noticed the problem before. However, in all of the protocols in all of the places where I’ve used the asn.1 library (and I still use it; I prefer asn.1 data streams to XML in my own ad-hoc protocols), I never had need to use the UTC time.
G’figure.
Why we shouldn’t unify mobile and desktop UI frameworks.
John Gruber: Google’s Microsoft Moment
It makes no sense to me why Chrome OS isn’t based on Android. Maybe there’s a good answer to this, but Google hasn’t given it.
While I don’t understand why Google has two completely separate operating systems, one based on Davlik (a Java VM clone) and another based on Javascript (sharing more in common with the Palm WebOS platform than with Android), I do know why no-one will ever be able to successfully create a framework that unifies mobile and desktop operating systems. It’s why Apple has a separate MacOS and iPhone OS UI framework.
It’s because of the needs of each platform.
Bottom line is this: on a desktop application you can create a rich window and environment that displays everything at once. The best example of this is the Apple Mail application: in one window I see all of my mailboxes, the status of all of my mail boxes, the list of mail in my selected mail box, and the current selected message.
Mobile applications, on the other hand, have limited real estate to work with. Thus, instead of having a single window, the iPhone version of Apple Mail has a separate windows for showing accounts, showing mailboxes in an account, showing messages in a mailbox, and showing an individual message. Within a mobile version of the software we also have a notion of a “view stack”; a stack of modal views which push and pop onto a stack of views–something that has no counterpart in the desktop world.
The development model also differs: on the desktop I may have a model and controller object (from the MVC design pattern) which drives multiple views simultaneously. But on the phone, I need multiple controllers attached to the same model, each controller contains information about what was selected higher up in the view stack.
Knowing that, we can answer the question that John Gruber links: “If I make a screen two inches smaller, should I use Android instead of Chrome OS? If the keyboard works with my fingers instead of my thumbs, I should use Chrome OS and not Android?”
The answer is simple: is the screen so small that your application must be represented as a stack of views (like the iPhone mail application) or can everything relevant be placed into a single window (like the Apple mail application)? If the first answer, use the mobile version of the operating system. If the latter, use the desktop version.
Touch screen dead zone.
While chasing down a usability bug, I discovered something interesting about the hardware for the Google developer phone, which I also suspect plagues the release G1 and G2 phones. The problem is an issue with the touch screen technology used by HTC.
The bottom line is this: there is a border to the left and right of the screen (and, I suspect, the top and bottom) where the finger’s location is not reported. On a piece of test software, when dragging my finger left to right, I found that when my finger was within 20 pixels of the left border, the position was reported as 0–and on the right border, as 319.0. This, despite being able to see my finger’s location reported with one- and two- pixel increments elsewhere on the screen.
I’ve also found that finger-down events within that 20 pixel border are not reported, unless accompanied with a drag outside of that 20 pixel border. Thus, if you design a UI where the user is expected to tap within 20 pixels of the border, the tap event will not be detected by the current hardware. A tap and drag, however, will be detected, which is why when you tap in the notification area at the top of the Android screen it doesn’t necessarily work–but a tap and drag will reliably open the notification area.
Just something to keep in mind when designing for the Android: tap areas near the left or right of the screen that may be 40×40 pixels in size will have the unfortunate problem that half of the potential touch area will be dead to tap events.
Javascript? Has it come to that?
Sometimes I really have to wonder at the sanity of the computer industry. It’s almost as if we do things because it’s the flavor of the week, not because it actually makes any damned sense.
Now for me, my own belief in what it takes to build good software boils down to (1) an expressive programming language, (2) adequate operating support for building the type of software I want to build, and (3) good IDE support. (By that I mean a development environment that allows me one-button compile and test. Because the key to writing great software is making the ‘edit-compile-debug’ cycle as short and painless as possible, with debugging tools that allow a direct correlation between what I write and what I debug. MacsBug is a last resort, not a development tool.)
I like the iPhone. It meets all three criteria. I like Android for the same reason.
I’m not a fan of Javascript because so far, I haven’t seen an adequate development environment. Now one may exist that I’m not aware of–but thus far, the best I’ve seen is a combination of Coda and Safari’s debug tools. Part of my problem is that a major part of Javascript programming involves manipulating a web page’s DOM, and, um, it’s not like Microsoft has ever played well with this whole “standards” thing.
I’m also not a fan of weakly typed languages. (One place where I draw an exception here is LISP and LISP variants such as Scheme–but then, really, all variables are references to objects, so it’s not as much “weakly typed” as it is “everything is either an ATOM or an object cell.”) And I’m really not a fan of Perl’s variable prefixing system.
So the idea of the Palm OS’s using Javascript for programming, or Google’s vaporware Chrome OS using Javascript: it just seems, um, weak.
Though one upside (I guess) would be a demand for a much better WebOS-based IDE. Because right now, Dashcode and the Google GWT both seem like hacks to me; rather than helping me write great Javascript they both hide everything behind a “helpful” layer of abstraction.
Development Chaos Theory 