© 2013 Fuji Xerox Co., Ltd. All rights reserved. ■JaSST 2013 四国 テスト分析・テスト設計入門 富士ゼロックス株式会社 ソリューション・サービス開発本部 秋山 浩一 2 自己紹介 1985年4月 富士ゼロックス入社 現在はHAYST法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会(ASTER) 理事 JaSST東京実行委員(2003年~) 日本最大のテストシンポジウム1600名の動員 JSTQBステアリング委員(2006~) テスト技術者資格認定を行う国際組織日本支部 日科技連 SQiP研究会 委員長(2011年~) Wモデル研究会 主査(2011年7月~) 電通大 西康晴先生、NEC 吉澤智美氏、MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26委員(20
今回のGoogle I/OではAndroidの新しいバージョンのアナウンスなどはありませんでした。 しかし、Google Play Service を中心に据えたかなり大きな機能追加があり、面白いです。 わからないことがあったら Y.A.M の 雑記帳 のセッションレポートを見るか、やんざむの口にカレーを注ぎ込むといいと思います。 Android の内容についてもっと知りたい人は 5/31(金)に行われる弊社の有料報告セミナーに是非きてください!(宣伝 僕はAndroid担当ですが、GoogleのCloudPlatformやGoogle Appsについても他の人が超しっかりキャッチアップしてお待ちしてます! 基調講演 Keynote 面白かった(小並感 主要なFeatureはすべて紹介されるので便利 GDGラウンジでKeynote視聴しながら爆睡する俺氏が多数報告された 新しい開発環境につ
34. スケジュール 先行開発チーム 仕様策定チーム 開発チーム 1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 ▼先行開発 ベースラインアーキテクチャの策定やコア機能を先行で開 発。何度となくハマったが、難易度の高い部分に取り組んだ ことによって早期に多くことを学習できた。 顧客 10年戦士 5年戦士 13年5月26日日曜日 35. スケジュール 先行開発チーム 仕様策定チーム 開発チーム 1ヶ月 2ヶ月 3ヶ月 4ヶ月 5ヶ月 6ヶ月 ▼既存システム調査 既存システム要件/機能を分析し、随時「仕様策定チーム」 と連携。テスト仕様書に積極的にフィードバックし、仕様書 の精度を上げていった。 顧客 10年戦士 5年戦士 13年5月26日日曜日
瀬良 @shela_ @irof publicからprivateを含めて検証するのと、private単体だけで検証するのであれば、先にprivate単体で検証しておいた方が安心感があると思う 2012-08-25 16:38:24
完全に新規の状態でのアカウント作成からiOS Developer Programを購入し利用可能にするまでの、できる限り撮り残したスクリーンショット集です。 日本のストアで購入すると一度サポートに連絡せねばならなくなると思います。そのトラブルを解決して購入・アクティベイトに至るまでを書いてあります。 追記:2014.5.20 法人登録についてですが、2014年版の「法人として iOS Developer Program に登録し、AdHoc用のプロビジョニングプロファイルを作成するまでの全スクリーンショット [2014]」を公開しました!個人での登録でも参考になると思います。 追記:2017.11 秘密鍵+CSR作成〜証明書作成〜.p12作成〜プロビジョニングプロファイル作成までの流れについて、2017年版を作成したのでこちらにもリンクを置いておきます。 2014年5月2日に大重さんの本「
git commitを実行あとでコミットをやり直したり、コミット自体を取り消す方法です。 直前にしたコミットをやり直す(git commit --amend) 直前にしたコミットをやり直す場合、「git commit --amend」を使用します。 例えば、直前のコミットログが以下のような状態だったとします。 実は直前のコミットに含めるべきであった「hoge.txt」が含まれていませんでした。 コミットログ(git commit --amend 実行前) $ git log commit cca638b48b4c8be7ad5432f7882497534b04e2b4 Author: mrgoofy <hogehoge@example.com> Date: Wed Sep 8 23:03:57 2010 +0900 2nd Commit.-> New Add File : bar.txtこ
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く