2. 自己紹介 湖山 翔平 / @sion_cojp 元FPSプロゲーマーでアジアチャンピオン qiitaをよく書いてます (http://qiita.com/sion_cojp) インフラエンジニアとしてよく使うコマンド集 インフラエンジニア 株式会社リブセンス

米Adobe Systemsが2011年10月3日と4日、米国ロサンゼルスで開催したイベント「Adobe MAX 2011」(関連記事1、関連記事2)。そこで発表された「Adobe Touch Apps」は、タブレットでWebページを作成できるツール群だ。正式発表は11月の予定で、日本公開時期はまだ未定だが、注目Androidアプリであることは間違いない。 そもそも性能にも限界があるうえ入力スタイルもPCとは違うタブレット。プロ用ツールベンダーのAdobeがどうしてタブレットアプリをリリースするのか?実際開発に関わるデザインフェーズに対してこうしたアプリは活用できるのか?気になるところだ。 自身がWebやアプリのデザインを仕事にしているAndroid女子部部長の矢野が、Adobe MAXの取材で得た情報から、タブレットアプリを仕事に活用する方法について考える。 Web作成のための7つの製品
いくつかの事に気をつけてコードレビューを実施するだけで、効率的にコードの品質を高めることができる。効果的なコードレビュー方法をまとめてみた。 (1)複数の有識者でレビューを実施する レビューアも人間なのでレビューが面倒になってしまうときもある。複数のレビューアが一緒にレビューすることによって、一人だけ「指摘なし」と言うわけにもいかず手抜きし辛くなる。 (2)事前に指摘事項をまとめておく ソースコードを読む速度はレビューアのスキルによって異なるため、レビュー時に読み合わせするのは時間がもったいない。調査が必要となることもあるし、じっくりと考えたいこともある。レビューは前もって行っておく。指摘箇所のフィードバックだけは対面で行うのがよい。 (3)印刷してレビューする エコではないが、指摘箇所を気軽に書き込めるのがよい。書き込み量をみるだけでレビューアがどれだけ丹念にレビューしてくれたのかが一目
ウォータフォールモデルによる開発手法の基礎(w) ...ソフトウエア開発手法の基礎をまとめてみました。 レビュー(r) ...レビューの仕方 コード作法・設計作法(c) ...コード作法 デバッグ(d) ...デバッグの仕方 JUnitとは(u) ...ソフトウエア開発手法における JUnitの使い道をまとめてみました。 eclipseメモ(e) ...eclipseのショートカットなど デバッグ技法について明確に書いてある。事例がハードウエアよりだが、文脈を読めば問題なくわかる。 ルールが9にまとめそれぞれがわかりやすく、基本的で大事な物ばかり。当たり前のルールだが意識化して行くにはとても役に立つ。デバッグ時に焦ってしまう人にお勧め
本来、レビュー/インスペクションでは全てのエラーを指摘すべきだが、実際には時間の制約があったり、かけられるコストにも上限がある。では、限られた時間やコストの中で特に何を指摘すべきか、以下の観点で紹介した記事が公開されている。(私がThinkITで書いたもの: 詳細はこちら) ユーザのユースケースの実行頻度の多いものから優先的に テスト工程での修正/確認テストの規模が大きいものから優先的に バグ票に含まれる修正時間の傾向をヒントに、修正時間の大きいものを優先的に 一般的なレビューであれば「テストでやるよりも効率的になるようにね」というくらいの合意が取られているのが一般的ではないかと思う。もう少し進んで、上述のような優先順位を検討すると、効率ががらっと変わってくるように思う。ご自身のレビュー/インスペクションにも活かせそうだろうか。ただし、コスト度外視で品質を極めて重視するソフトウェアやプロジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く