Simply No Excuse

Almost 13 years ago, I was a member of Netscape’s Technology Evangelism team tasked with helping promote a web based upon standards that could be accessed by anyone, using any browser on any operating system. Netscape is no more and the web is a much different place than it was in late 2000. In 2004 Firefox showed that alternative browsers were a reality and opened opportunities for others such as Apple’s Safari and Google’s Chrome. Apple and Google brought alternative devices such as smartphones and tablets to the web that were inconceivable in 2000.

Imagine my shock and dismay when I saw the headline from The Atlanta Journal-Constitution “Oregon exchange works with only one browser” in my Google Alert for Internet Explorer.

By limiting their web site to Internet Explorer, the State of Oregon forces their citizens to use not only Microsoft’s Internet Explorer, but also Microsoft’s Windows operating system. Users of Firefox, Safari, Chrome, OS X, or Linux are excluded from using a public web service to obtain a Federally mandated insurance policy.

There is simply no excuse for an Internet Explorer only web site to be developed in the 2013!

As I said over ten years ago:

The future belongs to developers and browsers which support standards. If you fail to take advantage of the coming change in browsers, your competitors will eat your lunch. Once that happens, the only place your web site will be found is on the web archive.

Autophone Status Update 2013-11-02

  • 7:15 AM PT – Swapped Kingston Class 4 4G sdcards for 00_23_76_96_cc_6f_nexus-one and c8_aa_21_ac_0c_b5_droid-pro after repeated failures checking for the device root.

  • 19:00 PM PT – Both 00_23_76_96_cc_6f_nexus-one and c8_aa_21_ac_0c_b5_droid-pro showed an inability to properly detect and use the external sdcard. I cycled through most of the previously used sdcards attempting to find ones that worked. After checking almost all of the remaining older cards, I found one that worked in the droid-pro but could not find a card that would work with the nexus-one. In my attempt to get a working patch for bug 933842 – Add ability to specify test root in SUTAgent.ini, I realized that mozdevice’s devicemanager.getDeviceRoot() caches the reported value of the test root. Since the autophone workers survive the rebooting of a device, the cached test root value is reused until the device’s worker is restarted. This means that once an incorrect test root is detected, it will not be corrected by rebooting the device. I am testing an preliminary version of the patch for bug 933842 on the nexus one which forces the test root to /mnt/sdcard. I have resubmitted all builds from 2013-10-31 to now for both nexus ones and the droid pro. Hopefully the devices will be more reliable. It may also be the case that the older sdcards are not as unreliable as initially thought.

    I also noticed that Autophone’s workers use devicemanager’s getDeviceRoot() to determine if a device is still responsive. Since the value is cached, this test is ineffective in determining if a device is still responding.

    phonedash results prior to re-testing nexus one and droid pro
    phonedash results prior to re-testing nexus one and droid pro

Autophone Status Update 2013-11-01

droid-pro-1 and nexus-one-2 sdcard change

nexus-one-2 (00_23_76_96_cc_6f_nexus-one) and droid-pro-1 (c8_aa_21_ac_0c_b5_droid-pro) appear to have difficulties with the new SanDisk Extreme Pro UHS-I. I have reverted back to the old Kingston class 4 4G cards on these devices. I have also discarded the older jobs which were pending so as to not confuse the graphs with a mixture of sdcards.

Any apparent regression from 2013-10-31 to 2013-11-01 for these two phones should be disregarded.

Kingston class 4 4G cards

I went through the older Kingston cards and performed a disk verification and repair using my Mac Book Pro’s disk utility. Those cards which could not be repaired have been removed from the active inventory. I will attempt to use the remaining cards in the devices which can not reliably run using the newer SanDisk cards. If a device appears to have issues with accessing the sdcard, I will attempt to swap in another and will move the offending card into an ‘unreliable’ category.

New Phones

I received a number of phones from Haxxor Canada and am in the process of bringing them online to help partition devices between the s1s2, canvas SkiaGL and regression testing.

New Phones
Phone Type DNS Name Device Name Notes
atrix-4g mb860 atrix-4g-1 40_fc_89_4c_95_3f_atrix-4g cyanogen mod7 – Android 2.3.7, new SanDisk sdcard
htc-sensation-4g htc-sensation-4g-1 18_87_96_a7_89_70_htc-sensation-4g Android 2.3.4, new SanDisk sdcard
htc-sensation-4g htc-sensation-4g-2 c0_3f_0e_ba_5f_34_htc-sensation-4g Android 2.3.4, new SanDisk sdcard, Rooted but unable to reboot via SutAgent.
sony-experia sony-experia-1 5c_b5_24_b6_7d_1f_sony-experia Android 2.3.4, new SanDisk sdcard
droid droid-1 a4_ed_4e_59_6c_b2_droid Android 2.1, new SanDisk sdcard
droid-pro droid-pro-4 98_4b_4a_13_01_84_droid-pro Android 2.3.3, new SanDisk sdcard
nexus-one nexus-one-3 90_21_55_09_87_95_nexus-one cyanogen mod7 – Android 2.3.7, new SanDisk sdcard
samsung-gs2 samsung-gs2-4 14_7d_c5_af_c8_e3_samsung-gs2 Android 2.3.5
samsung-gs2 samsung-gs2-5 04_46_65_fd_2f_e1_samsung-gs2 Android 2.3.4
samsung-gs3 samsung-gs3-3 38_aa_3c_1c_f6_94_samsung-gs3 Android 4.0.4