HTML５のAccesibility

スマートフォンアプリプログラマーの加藤です。

最近読んだ本にHTML5のAccesibilityについて書いてありましたので調べてみました。
(Accessibilityについて)

標準化を行っているのはW3Cです（http://www.w3.org/WAI/）。

2011/07でのブラウザサポートスコアは、

Google Chrome が155/370

Firefox が325/370

IE が280/370

Opera が110/370

Safari が180/370

です。

（HTML5 Accessibility サポートスコア計算方法は、

３７個のHTML５の新機能　x　１０ポイント　＝３７０ポイント

一部分のみ実装されている機能　=　－５ポイント

全く実装されていない機能　＝　－１０ポイント）

  HTML５アクセシビリティ新機能 (Windows Browsers)
     

HTML5新エレメント	Chrome 13	Firefox 6.0a2	IE 9	Opera 11.5	Safari/             Webkit r90881
article	非実装	一部サポート	非実装	非実装	非実装
aside	非実装	サポート済み	非実装	非実装	非実装
audio	非実装	一部サポート	一部サポート	一部サポート	非実装
canvas	非実装	非実装	一部サポート	非実装	非実装
datalist	一部サポート	一部サポート	非実装	一部サポート	非実装
details	非実装	非実装	非実装	非実装	非実装
figcaption	非実装	一部サポート	非実装	非実装	非実装
figure	一部サポート	非実装	非実装	非実装	非実装
footer	非実装	サポート済み	非実装	非実装	非実装
header	非実装	一部サポート	非実装	非実装	非実装
hgroup	非実装	非実装	非実装	非実装	非実装
color input	非実装	非実装	非実装	一部サポート	非実装
Date input	一部サポート	非実装	非実装	非実装	一部サポート
Date and Time input	一部サポート	非実装	非実装	非実装	一部サポート
Local Date and Time input	一部サポート	非実装	非実装	非実装	一部サポート
E-mail input	非実装	非実装	非実装	非実装	非実装
Month input	一部サポート	非実装	非実装	非実装	一部サポート
Number input	一部サポート	非実装	非実装	一部サポート	一部サポート
Range input	一部サポート	非実装	非実装	一部サポート	一部サポート
Search input	サポート済み	サポート済み	サポート済み	非実装	サポート済み
Telephone input	非実装	非実装	非実装	非実装	非実装
Time input	一部サポート	非実装	非実装	一部サポート	非実装
URL input	非実装	非実装	非実装	非実装	非実装	?
Week input	一部サポート	非実装	非実装	一部サポート	一部サポート
menu > context menu	非実装	非実装	非実装	非実装	非実装
menu> list	非実装	非実装	非実装	非実装	非実装
menu > toolbar	非実装	非実装	非実装	非実装	非実装
meter	非実装	非実装	非実装	非実装	非実装
nav	非実装	サポート済み	非実装	非実装	非サポート
output	非実装	非実装	非実装	非サポート	非実装
progress	非サポート	サポート済み	非実装	非サポート	非サポート
section	非サポート	一部サポート	非サポート	非サポート	非サポート
summary	非サポート	非実装	非実装	非実装	非実装
video	非サポート	一部サポート	一部サポート	一部サポート	非サポート

 

  HTML5アクセシビリティ　新 （Windows Browsers）
   

HTML5 新アトリビュート (一部分のみ)	Chrome 13	Firefox 6.0a2	IE 9	Opera 11.5	Safari/             Webkit r90881
hidden	サポート済み	サポート済み	非実装	サポート済み	サポート済み
required	非サポート	サポート済み	非実装	非サポート	非実装
placeholder	非サポート	一部サポート	非実装	非サポート	一部サポート

例文：
<fieldset>


   <legend>Meeting alarms</legend> 


 <!-- Rule 2A: "Beep" label given by native HTML label element --> 

  
<input type="checkbox" id="beep">
 <label for="beep">Beep</label>
 <br>

 
<input type="checkbox" id="mtgTitle">
 <label for="mtgTitle">Display the meeting title</label>
 <br>



<!-- Rule 2B: Full label of checkbox includes value ("3") of embedded text input, "Flash the screen 3 times" --> 

   <input type="checkbox" id="flash">

  
<label for="flash">

     Flash the screen

    
<!-- Rule 2A: label of text input given by aria-label, "Number of times to flash screen" --> 

     <input type="text" value="3" size="2" id="numTimes" aria-label="Number of times to flash screen">

     times

  
</label>


</fieldset>


aria-label というのがWAI-ARIAのタグになります。

あるAndroidアプリで積んだ経験

初めまして。

入社二年目の中国人の謝です。

テクノロジストに所属しており、

主にAndroidアプリ、サイトなどの開発を担当しており、

最近はソーシャルゲームの苦戦をしております。

日本語がおかしいところもいっぱいあると思いますが、指摘していただければ幸いです。

今日は自作のAndroidアプリで積んだ経験を紹介したいと思います。

まずアプリの機能を簡単で紹介したいと思います。

一言といえば、場所、時間より音声モード、Wifi、BTを自動的に切替えてくれるアプリです。

ポイントは

１、バックグランドで安定的に実行できること

２、正確な場所をゲットする

３、電池消費を抑えること

僕も完璧に解決できていないと思いますが、恥ずかしながら自分の方法（正しいのかなぁ）を紹介したいと思います。

１、バックグランドで安定的に実行できること

アンドロイドの経験者ならすぐわかると思いますが、サービスで対応すれば解決できるでしょう。

僕も最初簡単だと思ってましたが、大変だった。

もっとも苦労したのは、「定期的に」GPS情報を取得することです。

定期的といえばタイマーはもっとも使われていますが、

このアプリでは使い物になりません。

アンドロイドは自動的にメモリを解放する仕組みになっている。

そして、端末のメモリ状況より、タイマーも解放されてしまうのです。

しかもいつ解放されたのか、全くわかりません。

自分の知っている限り、唯一の解決方法は「AlarmManager」を使うことです。

メモリいっぱいになっても、

電力が足りなくても、

端末はスリープになっても、

端末が死ぬまでAlarmManagerはちゃんと働きます。

２、正確の場所をゲットする

３、電池消費を抑えること

みなさんご存知だと思いますが、GPS情報取得するのはバッテリー消費がめちゃめちゃ激しいです。

普通にGoogleマップを３時間連続使って、耐えられる端末おそらくまたないでしょう。

アンドロイドは２種類のGPS情報を取得できます。

１、LocationManager.GPS_PROVIDER　　　　　衛星GPS情報取得

２、LocationManager.NETWORK_PROVIDER　　　ネットワークGPS情報取得

衛星GPSのメリット

１、比較的に正確なGPS情報取得できます。

　　→自分の経験だと誤差20メートル以内。

　　　Googleマップと同じレベルのGPS情報取得できないようです。

　　　GoogleはGPS情報悪用されないために、わざと精度を下げたようです。

２、携帯の電波に依存しない

　　→登山アプリなど

衛星GPSのデメリット

１、バッテリーの消費は激しい

２、屋内はほとんど取得できません

ネットワークGPSのメリット

１、バッテリーに優しい。

　　→２分一回携帯回線GPSを取得しても、電池消費ほとんど変わりません。

２、屋内も取得可能

　　→絶対とは言えないですが、基本的には問題ないです。

　　　※取得できない高級ビルもあるらしい。（原因不明、ご存知の方がご教授ください！）

ネットワークGPSのデメリット

１、ざっくりとしたGPS情報しか取得できません

　　→地域により誤差も大きいです。

　　　僕が住んでいるところだと、誤差は70メートルがありますが、

　　　いろいろなところで試しましたが、遠くなっても150メートルぐらいです。

　　　ほかのユーザからのフィードバックよると、５KM以上もあるらしい。（端末のせいかなぁ．．．）

実装する際、まず衛星GPS情報取得してみて、10秒間取得できなかったら、ネットワークGPS情報を取得して、

それでも取得できなかったら、getLastKnownLocation（最後取得したGPS情報）を使うっという組み合わせでもいいかもしれません。

補足ですが、ネットワークGPS情報も２種類があります。

１、Wifi

２、基地局

Wifiに接続している場合は、もっとも正確なGPS情報取得することができます。

※WifiでGPS情報取得するのもバッテリーにすごく優しいですが、WifiOnにするだけで、パッテリーを食ってしまうのです。

以上、ご参考になれば幸いです。

情報セキュリティの話

初めまして。老けた新人、まるやまです。

情報セキュリティに関するお話です。

まずは下記の事故事例を。

■ケース１

会社のPCを許可無く持って帰宅。途中で飲み屋に寄り酔って帰宅中に、PCをカバンごと紛

失した

＜規則＞

・PCを許可無く持ち出すことは禁止されている

・PCに限らず申請して持ちだしたものを自宅に持ち帰る場合は、紛失しないよう管理する

　義務あり

■ケース２

取引先の会社に訪問し、個人所有のUSBメモリからデータを取引先会社PCにコピー。その

結果取引先会社のPCをウイルス感染させてしまった

＜規則＞

・個人所有のUSBメモリは使用禁止

・許可の無いUSBメモリの持ち込み禁止

・許可を得て持ち込んだUSBメモリも使用前にウイルスチェックが必要

上記ケースはいずれも「よくもここまで」というくらい見事に規則に反しているものです。

このような事故を起こしてしまった人も、まさかこんなことになろうとは思ってもみなかっ

たことでしょう。

情報セキュリティの問題は、今やITに関わる者にとって知らぬものはいない、といっても

いい問題であると思います。プライバシーマークなどのセキュリティ関連の認定を取得し

ている会社も多数あります。にも関わらずセキュリティ事故は起こり続けてます。事故と

はならないセキュリティ事象も含めれば、途方も無い数の問題が発生していることになり

ます。

何故事故は発生するのでしょう？　セキュリティ教育を定期的に受け、情報セキュリティ

に関する様々な情報に接していて、それでも事故を起こしている、というのが現状です。

ここでちょっと話を変えまして、、、

情報セキュリティではありませんが、某漫画にて、主人公が暗殺や誘拐といった犯罪から

身を守るための講習会を実施する、という話がありました。一通り話が終わった後の質疑

応答で、ある参加者から「そのような知識は皆知っているはずだ。それでも被害にあうと

いうのが現状だろう」という指摘を受けます。「ではどうしたら身を守れるのか」という

問に対する主人公の答えはこうでした。

「徹底すること」

質問者はこの答えに感銘を受け・・・、というお話です。

話を戻します。

情報セキュリティ対策についても同様です。

何をしていいのか、悪いのか、皆知ってます。知っているだけでなく実践もしているで

しょう。

であれば、後はこの実践を「徹底すること」です。

規則は指針に過ぎません。あくまでも私たち自身の意識、行動によります。

私たち自身が高いセキュリティ意識を持ち責任ある行動をする。そしてそれを「徹底する

こと」こそが、あるべき情報セキュリティ対策であると考えます。

見積りは確かなものなのか？

はじめまして、モンスター・ラボ、テクノロジーグループの山口です。

Linuxサーバによるインフラ構築から、

フレームワークを使ったPHPによるサーバサイド開発などメインに担当しています。

最近、自分の参画する開発プロジェクトの規模が大きくなってきたこともあり、

技術だけでなく、プロジェクトの管理や開発プロセスを学習することにも関心が高まってきました。

今日は、その第一弾としてソフトウェアの見積りについて書いてみようと思います。

スティーブ・マコネル著「ソフトウェア見積り」という本が参考書です。

興味のあるかたは、是非、読んでみてください。

■見積りは何のためにするのか

「このプロジェクトの所要期間は14週間である」といったとき、

この見積りはどのくらい確かなのでしょうか？

実はこのように単純に単一の期日を提示した見積りは、

意味がないと著者のマコネルさんは言います。

なぜなら、確率が考慮されていないから。

確かにこの14週間は、どの位の確率で実現可能なのか、背景となる情報もないため、

「これは単なる目標なのではないか？」と実現性に不安を感じてしまいます。

例えば、下のように確率を明示した見積もりは、良い見積もりと言えるとのこと。

「24週間のスケジュールで完了する確度は90%」

「最良で18週間、最悪で24週間」

まず、初期の見積もりではターゲット（ビジネス上の目標）と見積りに

どのくらいギャップがあるのか把握することが肝心です。

※見積り名言１

「ソフトウェアの見積もりの主目的は、プロジェクトの結果を予言することではない。

見積もりを行うのは、プロジェクトのターゲットがコントロールによって

達成可能な程度に現実的なものかどうかを判断するためである」

■見積りはいつ明確になるのか

では、確率を考慮した幅のある見積りというのは、

いつ明確な見積りに収束していくのでしょうか？

不確実性のコーンという、面白い図があります。

プロジェクトの最初に行った見積りは不確定要素が多いため大きな誤差がありますが、

プロジェクトが進むにつれて、ばらつきがなくなっていきます。

詳細設計が完了するころには、確度の高い見積りが可能になっています。

再見積りによってプロジェクトの見通しが明確になってくれば、

計画に有益な新しい情報が得られるはずです。

再見積りの計画を前もって関係者に伝えられるのがベストですね。

■過小見積りと過大見積りはどちらがよいか

「意図的に過小見積りをしてはいけない」この教訓は大事です。

○過小見積もりで発生する問題

・実際に必要な人数より小さなチームにしてしまい、必要な準備がまにあわないことが続出

・予定どおりに完了する機会が減少

・要求定義や設計のような上流工程に費やす時間が不足

・「遅延」状態に陥ると、「予定どおり」に行われている間には必要なかった活動が大量に発生（打合せや関係者への説明、議論など）

過大見積もりで余裕ができると、メンバーが怠けてしまうのではないかと心配するかもしれませんが、それよりも、過小見積もりで発生する問題の方がはるかに深刻です。

■見積りに見落とされがちなもの

見積りはできる限り判断に頼らず、「数える」「計算する」ことを重視べきですが、

数え上げるときに、見落としがちなものを参考までにあげておきます。

○機能要求

セットアップ/インストールプログラム、データ変換ユーティリティ、ヘルプ

○非機能要求

セキュリティ、ユーザビリティ、再利用性

○ソフトウェア開発アクティビティ

新しいチームメンバーの指導、マネージャミーティング、テストデータの作成、パフォーマンスのチューニング

○その他

休暇、トレーニング、週末、全社ミーティング

などなど

■最後に

見積りというのは、

詳細なスケジュールを作成し、機能の優先順位付けを行い、クリティカルパスを特定するなど

現実的なプロジェクトの計画を立てるための根拠となる、最も有益な情報の一つだと考えています。

まだまだ、開発プロセスについて勉強中ですが

今後、「うまくいく見積りフロー」を作っていくための

参考になれば幸いです。

要件追跡システムの実装に有効なツール「zeeta」

初めまして、モンスター・ラボのMr.ポポです。
デザインテクノロジストとしてスタートしましたが
最近はWebサービスの開発・保守などほとんど
テクノロジストとしての内容が中心です。

現在携わっているプロジェクトでテストケースを作成しています。
テストケースの作成にこれまで自分がやったことのない方法を取っており、
また本案件では要件開発フェーズから従事しているのですが、
現在の作業のことまで通して見えていたらもっと効率化できたのになと
思うことがあったので共有したいと思います。

実はテストケースの作成に限らず、プロジェクト全体の
知識の共有にZeetaというツールを使用しています。
このZeetaについてのもっと奥深い話はZeetaの作者である
Zeeta博士が今後のエントリーで触れてくれるかもしれませんので
割愛しますが、共有したいことを説明するのに最低限のことだけ記述します。

Zeetaは階層構造で情報を管理するツールで、一つ一つの情報の要素を
「ノード」と呼ぶのですが、このノードが複数の親を持ててなおかつ
「逆ツリー」といってノードの親のツリー構造を辿って参照することができます。
また、ツリーの内容をテキストで検索することができます。
こう書くとシンプルなのですがこの構造が「つかそもそも何でこんな機能
実装するんだっけ？」とか「確かあの時そんな話をお客さんとした気がした」
といった事の事実関係を辿る必要があるような場合に相当威力を発揮します。

CMMI(v1.2)の「要件管理」プロセスの中に下記のようなSPがあります。
-----------
SP 1.3 要件変更を管理する（以下一部抜粋）
プロジェクト実行中、要件はさまざまな理由で変更される。ニーズの変化および
作業の進行に伴い、追加の要件が導出され、既存の要件に対して変更を行
うことが必要になる場合がある。このような追加および変更を、効率的かつ効
果的に管理することが必須となる。変更の影響を効果的に分析するには、各
要件の出所が把握されており、すべての変更の論理的根拠が文書化されてい
る必要がある。

典型的な作業成果物
1. 要件の状況
2. 要件データベース
3. 要件決定データベース

SP 1.4 要件の双方向の追跡可能性を維持する（以下一部抜粋）
要件がうまく管理されていれば、原要件から下位レベルの要件、
および下位レベルの要件から原要件への追跡可能性を確立できる。
このような双方向の追跡可能性は、すべての原要件が完全に取り上げら
れているかどうか、およびすべての下位レベルの要件を有効な出所まで追跡で
きるかどうかを判断するのに役立つ。

典型的な作業成果物
1. 要件の追跡可能性マトリクス
2. 要件追跡システム
-----------

要件がコロコロ変わるのでプロジェクトのスケジュールがどんどん圧迫される
というのは良く聞く話なのですが、元の要件をきちんと管理していれば
変更を変更として顧客と交渉する余地が生まれるはずです。
実際この要件の管理には変更の頻度や全体のスピード感を考えると
どえらい手間がかかるので腰が及びがちなのですが
プロジェクトの死線とも言える大事な管理項目ですよね。

このCMMIで書かれていることもわかっちゃいるけどじゃあどうやって実現
すりゃいいの？という気になります。字面だけ見ると「要件データベース」やら
「要件追跡システム」やらそりゃ必要でしょうよと思うのだけれど
このプロセスをどのように実装すればというのが大きなクエスチョンです。

その点で前述のZeetaを使った要件の管理は制約が多くスピード感が
求められることが当たり前のWebサービス開発プロジェクトの中で、
最小限の管理コストでやりくりすることができる可能性のある
優れたツールだなと使っていて感じています。

冒頭に触れたもっと現在の作業が通して見れていたらなと思ったのは
要件開発の際にノードを作成する際に最初からテストケースで使用する
言葉としてかけていたらそのノードをテストケースとして共有して
使用可能なものがたくさんあったなという実感です。
さらにもっと言えば、画面設計がだいたい終わって機能がおおよそ
確定できたところでそれを詳細化するという作業を要件を詳細していく
という作業ではなくテストケースを作成するという作業で行ってしまえば
良かったなと今では思っています。

テストケースは色々なケースを想定して具体的にここを押すとどうなるの
ということを詳細に決めていないと書けないため、要件の落としが
不完全であったことが後からわかって要件を追記するようなことがまま
あるし、色々なテストパターンに対して並列的に考えることが多いため
抜けていた要件が見つかるということが多いのです。
もちろんなぜそのテストパターンになるか、というのは要件から
派生するのがふつうなのですが、要件があいまいなことも多いので
固めたことを提案して承認を取るという進め方が主なプロジェクトでは
特に有効な手段だと思います。
また、テストケースと要件の結びつきがより強固になるので
要件の妥当性確認もより確実になるのも嬉しいですね。

実際使い込まないと伝わりづらいかもしれないので興味を持った方は
Zeetaに触れてみるのも良いかと思います。
http://sites.google.com/site/zeetahp/