Ich bin ja leider immer noch Kunde bei der HypoVereinsbank, dem Kernkompentenzteam unter den Schokobanken. Nicht, dass die anderen besser wären, aber hier sind meine persönlichen Highlights für 2012:
- Nachts schalten sie immer noch das Internet-Banking aus. Buchungslauf, weißte?
- Disketten (!) mit Buchungen zum Jahresschluss bitte bis 27.12. einreichen.
- Der Online-Kontoauszug funktioniert genauso wie der Auszugsdrucker. Anfordern, genau einmal herunterladen, danach ist das PDF weg.
- Update: Die PDF-Auszüge liegen immerhin eine Weile in einer Inbox, die sich dann aber nach 6 Monaten wieder deaktiviert.
- Seit ein paar Monaten haben sie einen Online-Berater per Videokonferenz. Da haben sie sich von den Citrix-Sales-Droiden bequatschen lassen, dass sich die Bankkunden prima Citrix-Client vom US-Server auf dem eigenen Rechner installieren, um mit einem Mitarbeiter zu sprechen.
- Mobile TANs finden sie auch ganz dufte. Inklusive der Kontonummer und des Betrags in der SMS. Da können die Android-Trojaner gleich noch mehr auslesen, als sie brauchen.
Aber den Vogel schießen sie gerade mit diesem Banner für Neukunden ab. Der/Die/Das USP: Nimm doch deinen Hochzeitstag als PIN für deine EC-Karte.
Update 2013-01-09: Die Kampagne auf der Startseite ist raus, und auf der Neukundenseite spart sich die Schokobank jetzt auch den Hochzeitstag. Einsicht oder normale Aktualisierung?
On the German show Bits und so two of our regulars are remote. Leo in Wiesbaden, Germany, and Alex in Helsinki, Finland. The studio is in Munich, Germany. For the past couple of years, they’ve joined the conversation via Skype, as so many podcasters do. The reliability and quality of this service has been flaky, and even worse, it seems that nobody at Skype seems to care. Apart from terrible UI updates, the underlying codecs and protocols don’t seem to get any attention in a shipping client. A new feature we tried using for a while was paid multi-user video chat, which always resulted in inexplicable audio quality degradation. We had to switch back to one person per Skype machine.
I’ve been evaluating alternatives such as iChat (remember that?), Facetime, SIP software phones, ISDN hybrid codecs for a long time, but despite the pain, none would even come close to the relative ease of use, reliability and quality of Skype. And Skype is horrible. Go figure.
For the past three months, we’ve been evaluating Mumble 1.2.4 with Opus support and won’t be looking back at Skype anytime soon. Read more details on Opus at the Auphonic Blog.
Mumble appears to have been developed, similarly to Teamspeak, with gaming in mind. The idea is to start the client, connect to a server and let the connection run in the background, while you play your game.
Mumble’s server (named “Murmur”) can be run locally provided you have sufficient upstream bandwidth. In most cases, you will want to run the server in the cloud. We tried both cheap virtualized boxes and a dedicated high end machine and didn’t really see any differences. CPU load should be minimal, and as long as you’re talking about a handful of participants, network bandwidth also will be minimal percentage wise on a 100 MBit/s connection.
Our server now is located somewhat centrally between all participants, in Falkenstein, Germany. Geographically and network topology wise.
By having an open channel, participants can dial into that channel whenever they want – the host doesn’t need to take action when somebody loses their connection and needs to reconnect.
The defaults in the Mac client are a little odd. We found that disabling all sound processing, transmitting continously and setting “Audio per packet” to the minimum value of 10 ms, we achieve our goal of a high quality, low latency connection that will not cut out when multiple people are talking at once. This of course requires all ends to minimize all crosstalk from headphones to microphones, or all echo will be transmitted as well.
There’s also a bunch of notification sounds that need to be disabled on both ends.
Mumble also comes as an iPhone app (no Opus support in the App Store yet, need to build it yourself from source) which enables high quality voice calls even on a 3G connection. Again, weird default settings that need some massaging. Turn on continuous transmission and disable any sound processing.
SILK, Skype’s standard audio codec is specified at a maximum sampling frequency of 24 kHz. This means that frequencies above 12 kHz will be cut off. This gives you the typical Skype sound you’re used to. The maximum bitrate is 40 kbit/s for SILK.
But we really don’t need to be restricted by this codec nor by very low bitrates. Even on the somewhat archaic DSL line in Finland, we have 1 Mbit/s upstream.
With Opus over Mumble we gain the ability to set the audio bitrate manually. We found that anything over 70 kbit/s sounds really great, and 40 kbit/s still is much better than Skype on a good day. Also, the signal contains frequencies up to 16 kHz, implying there may be a low pass or some 32 kHz sampling frequency in the signal path. Unlike Skype, there’s no level compression or hard limiting built-in, which means that you should be extra-careful not to clip the input and that you need to take some extra care in processing the signal yourself in post or on a hardware audio processor.
Opus has a default codec latency of 22.5 ms, configurable down to 5 ms, although I’m not sure which value is used in the current implementation. Anyway, it’s lower than 25 ms with SILK.
Syncing with Skype Video
So you want to look at each other or want to broadcast the webcam image as well? Just run a Skype video session in parallel, with mics and Skype audio muted. This will reveal the higher latency Skype provides over the very same connection. The result is a very visible and audible ~100 ms delay of the video. Usually, that might be a deal breaker, but in our setup this is actually really great: Our little HDMI cameras that record the images from the studio introduce a similar visual delay and lag behind the audio. All we need is to delay audio for 80 to 100 ms and all sources will be in sync again.
Optimizing UDP Latency
With increased manual control over the protocol, we can try to optimize latency even further. As Murmur will not mix the audio on the server and provide each participant with their own mix, but will only forward individual streams to all participants, you may look into running the server locally, to minimize latency from Murmur to your local instance of Mumble. Local latency on the loopback device should be well under 0.1 ms. This would provide you with a minimal latency “truth” on your mixing board.
In our case though, this theoretical advantage does not help in the real world.
Comparing ping times from Helsinki to Falkenstein (avg 90 ms) to ping times from Helsinki to Munich (avg 160ms) and a quick traceroute shows that the Finnish ISP has better peering to Germany over DE-CIX to Falkenstein and a much slower route, via Sweden, to the network of Deutsche Telekom where my VDSL line is hooked up.
|Munich||25 ms||0.1 ms|
|Wiesbaden||25 ms||25 ms|
|Helsinki||90 ms||160 ms|
Adding the 25 ms from the studio in Munich to the server in Falkenstein gives us a better latency to Helsinki (25 ms + 90 ms = 115 ms) than directly from Helsinki to Munich (160.1 ms)
After 10 episodes (combined runtime: ~30 hours) we’re quite confidently using Mumble as a vastly superior alternative to Skype for our purposes, enjoy much more lively conversations without anyone cutting out, reduced latency and increased audio quality. Skype is demoted to providing us with a moving image.
The increased work to set this up may not be for everyone, but for professional, regular shows this little effort will pay off in a huge way.
As we’ve seen in an ever increasing number of examples, relying on third party services will at some point come back to bite you. Whenever Skype goes belly up or turns super evil, we’re covered, at least for the audio part. The irony in that is of course that Skype is heavily involved in the development of Opus, but so far no Skype version supporting it has been published.
Update 2013-01-22: Read more on how to set up Mumble for optimized latency and audio quality.
I’ve had it with Twitter and their quadrants. Nobody leaves email, nobody leaves blogs, right? So here you go. I own my content and can move it freely whenever and wherever I want. BTW Dick, where’s that Twitter Exporter you promised this summer?
I crossposted a bunch of old posts from the Undsoversum Blog that really didn’t fit over there.
When the App Store launched in the summer of 2008, four years ago, the exchange rate EUR/USD was at around 1 EUR = 1.58 USD. Accordingly, the conversion for the European App Store was something like this:
0.99 USD / 1.58 = 0.627 EUR
Subtract Apple’s cut of 30% from this to arrive at the payout of 0.44 EUR.
Add 15% VAT to 0.627 EUR for iTunes Sàrl in Luxembourg, who acts as the operating legal entity for Europe: 0.627 EUR * 115 % = 0.72 EUR.
N.b.: This tax rate is valid for all European customers, regardless of the developer’s or the customer’s nationality. Look it up in European Council Directive 2002/38/EC and amending Directive 77/388/EEC.
So, to get a nice price, Apple rounded 0.72 EUR to 0.79 EUR, giving them leeway to a USD exchange rate as low as 1.44 EUR.
As to why the adjustment happend now – who knows what Apple’s rules for this look like. The Dollar dipped below 1.44 EUR a couple of times in the last four years.
So right now the calculation is:
0.99 USD / 1.29 = 0.767 EUR
Add 15% VAT: 0.767 EUR * 115% = 0.883 EUR
Round that up to nice-looking 0.89 EUR.
To arrive at the new developer payout: 0.89 EUR / 1,15 * 70 % = 0.54 EUR.
Across the 87 regular price tiers, the increase in retail price roughly is between 9% and 20%, accounting for some very irregular rounding at some tiers.
Prepare yourselves for the next adjustment when the exchange rate stays below 1.15 for a while.
How does this affect auto-renewing subscriptions? The basic rule is: If the developer racks up the price of a subscription, the subscriber will be notified when his renewal comes up and the subscription will not be renewed automatically. What happens when Apple increases the retail price?
My guess would be that the customer will be billed the new price automatically. Guessed wrong. They cancel all subscriptions.
Update: Decrementing the price tier to match (or possibly undercut(?)) the old Euro price will keep subscribers on their auto-renewing plan, but will reduce revenue outside of Euroland accordingly.
Digital dead-tree publishers get special sauce for price tiers 1b (0,99 EUR) and 2b (1,99 EUR). As far as I can tell, these are only valid for Newsstand subscriptions, and stay the same after the adjustment, at the lovely exchange rate of 1 EUR = 1 USD. A recent addition to price tier 2b appears to be The Magazine.
So, Passbook is perceived having a bad start. The special App Store category is mostly empty, and support in the few companies that support it seems rushed or is spotty.
Implementation is not trivial, but easy enough. Passes are a zipped bundle containing images, pass data in a json structure and a cryptographic signature. Updates to passes are triggered with push notifications. Any half-asleep Java developer can whip that up during his coffee breaks.
One feature that is included in Passbook but hasn’t got any attention is that they’re location-based. Any pass can contain a number of locations that will set up geofences on the iPhone and will present the user with a prompt to go into your store and spend some money when they’re nearby. When I got close to the Subway’s location, the notification popped up silently, and when I left, it disappeared again. A loyalty card pass for a larger chain could update itself to notify the user when they’re near one of their five most frequented branches.
The marketing departments should be falling over themselves to implement Passbook. Guess nobody told them, including Apple.
Note that this pass is self-made and is not actually supplied by Subway.
With Xcode 4.5 reportedly dropping support for armv6 binaries (iPhone Classic and iPhone 3G) and therefore deployment targets below iOS 4.3, actually continuing to use these devices gets increasingly harder.
Apple has half-baked measures in place that could alleviate this issue, but it appears to be broken.
Let’s say I’m using my iPhone Classic on iOS 3, and GreatApp 1.0 supports this hardware.
The developer decides to support iOS 6 and iPhone 5 using Xcode 4.5 and therefore has to drop armv6 support with GreatApp 2.0.
The device will not install the update because it’s incompatible. But iTunes on Mac/PC will download the update and replace the 1.0 .ipa on disk.
Now the device needs a restore from a backup. iTunes lost the 1.0 ipa. And the device is unable to get the older version from the App Store, because only the latest version is listed.
In iTunes Connect, there is an option to “indicate a legal issue with this version“. According to the wording on the page, this should make this version unavailable to redownload. This would also imply there was some way to access those old versions. But there is none.
Even when accessing the old purchase directly (viewSoftwareRedownload URL), the store seems to present only the latest version to the user, even if it’s incompatible.
With an ever-increasing number of older devices floating around, Apple should make sure customers have a way of restoring those devices to a somewhat usable state even when apps get their unevitable updates and drop explicit support for old devices.
The App Store should enable old devices to actually download the last compatible version of an app through the iTunes in the Cloud / iCloud mechanism, a.k.a. App Store / Updates / Purchased.
Developers should have a clear way of indicating which old versions should stay available. The “legal issue” indication is there already, but worded confusingly and apparently quite useless.
While the result was confirmed by BlueToad, his intermediary assumption about the APNs tokens is not correct.
Interesting. Just noticed there are UDID duplicates in that data dump, with multiple APNS tokens. Different app providers, or multiple regs?
UDID duplicates do not come from multiple app providers or multiple apps. Any production app on a single device will get the same token. E.g. Facebook and WhatsApp will get the same token on the same device at the same time.
- the user switches devices, regardless of restored backups
- the user restores a device to factory settings and does not restore his old backup
- (possibly some Apple certificate expires, maybe once every year or two, maybe at major iOS updates)
Tokens appear to be derived from some device specific data (maybe the UDID), a key applied at device activation, and possibly Apple’s certificate.
So the duplicates likely stem from development devices being restored to new OS versions, as is apparent from some of the device names as well. “iPad 4.2” vs “iPad 4.3.1” on the same UDID.
Another way of one device having multiple tokens at the same time is production vs sandbox environment. But at any one time, a device will not have more than those two tokens (in the App Store context, MDM may be another story).
Another interesting data point are identical APNs tokens on differing UDIDs in the data set. By all accounts, this should be impossible, as confirmed by Apple (iOS Dev Membership required).
Q: Do we need to sand down our fingers to a quarter of their size to operate a 7″ or 8″ iPad, as Steve Jobs suggested in an Earnings Call in 2010?
The iOS Human Interace Guidelines say that some things do not change across all iOS devices, e.g.
The comfortable minimum size of tappable UI elements is 44 x 44 points.
There are two screen sizes on iOS: 480×320 and 1024×768 and they need to stay like that if Apple doesn’t want to break all three bazillion Apps.
Look up the physical display dimensions on the technical drawings on Apple’s site. They change by a millimeter or two across device generations, but they give you a good idea of how big the displays are.
On the iPhone/iPod touch, this translates to a minimum physical tappable size of:
(Display width / Horizontal point dimension) x minimum tappable size
(50mm / 320pt) x 44pt = 6,875mm
On the existing 9.7″ iPad:
(149mm / 768pt) x 44pt = 8,536mm
If one was to shrink the 1024×768 display from 9.7″ to let’s say 7″, the screen would have a portrait width of around 107mm.
(107mm / 768pt) x 44pt = 6,13mm
This would be 11% smaller than on the iPhone, on a device you usually hold at a far greater distance.
And at 8″:
(123mm / 768pt) x 44pt = 7,05mm
The 8″ display would come in at 160ppi, very close to the original iPhone at 163ppi.
This would actually match the physical size on the iPhone, and most apps adhering to the 44x44pt finger would still be operable without any changes.
A: No need to sand down your fingers.
I tried submitting an app that plays back an audio podcast as a Newsstand app to benefit from the Newsstand-only features, true background downloading and dynamic covers. A long shot, I know, but someone had to try.
After two very long rounds of reviews and a App Review Board appeal, the app was rejected after 5 weeks for “not being primarily written content”.
This requirement could be implied by the way Newsstand looks and feels, of course. But nowhere in the semi-public review guide or in the dev agreements do they actually say it. When following the documentation’s requirements literally is not enough, Apple has to work on their public review guide. Developers need clarity up front about what is acceptable and what is not.
I have a feeling that there are a lot of obscure new guidelines in place at App Review and the documentation available to developers is very incomplete.
Another guideline that I was made aware of: “Don’t use wooden shelves for your Newsstand app.” Wooden shelves are for the Newsstand folder only. Oh, and iBooks. But you really don’t want to use shelves in your app. For magazines. Silly you.
Meanwhile, one-star rip-off apps claiming to provide services that are impossible under iOS (custom lock screens etc.) are on top of the sales charts.
Apps are the new channels, but meanwhile podcasting is getting shoved further back every year in the iTunes Store. Getting a little worried about Apple’s intentions there.
Right now, the podcast directory still is maintained, but I see this going the way of the dodo. If you don’t have your own app to distribute your content, sooner or later, you may be out of luck. (Need one? Ask us.)