待ちイベントに関する検証 その１ - InsightTechnology 旧ブログ
＜待ちイベントに関する検証 その１＞ ペンネーム： ダーリン 【SQL*Net message from/to client】 焼き芋が恋しい季節になりました。I can’t wait for YAKIIMO !! しかし、「いーしやーきいもー、焼き芋っ。」の声は聞こえても、こっちに来 てくれないことには、なかなか焼き芋にありつくことができません。待てば待 っただけのありがたみはあるのですが、それが Oracle データベースへの問い 合わせの結果となると、ありがたいどころかイライラするだけです。 このメルマガではこれまで Oracle の待ちイベントに絡んだ検証をたびたび 実施してきましたが、今回は少し視点を変えて SQL の処理を追いかける形で ポイントでの待ちイベントを追いかけてみたいと思います。 Oracle でパフォーマンスチューニングを実施するときは、いくつかアプロー チがあり
テスト戦略、設計、手法、技法などなどのリンクをまとめてみた - うさぎ組
WACATE 2011 夏に申し込んだので、おさらいしましょう。ということでテスト手法、テスト技法を中心としたリンクをまとめてみました。 なので今回はTDDとかテストツールとかはあまり含まれていません。 いくつかかぶっているものもありますが、多面的な表現って大切だと思うので、多少のかぶりは気にせずに選択しました。 これを読めば良いソフトウェアエンジニアとして一歩階段を上れる気がしています。 他にも参考になるものがあったら、コメントやTwitterで@kyon_mmまで教えてくださるととっても嬉しいです！ 次の形式で書いています。 WEBサイト名、資料名：発表者（敬称略）：URL カテゴリー分けしたんですが、不適切であるかもしれません。間違い等あればご指摘ください。 また、ここでのリンクに問題がある場合は削除致しますので、その場合もご指摘ください。 TwitterID:kyon_mm mai
プログラミング用フォント Ricty
お知らせ Ricty および Ricty Diminished は、2010 年代前半には欧文・和文合成プログラミング用フォントとして先駆的でしたが、現在は前時代的な存在となっています。不具合もいくつか確認されています。良質なプログラミング用フォントが数多く登場していますので、それらの利用をおすすめします。 序文 Ricty（リクティ）は Linux 環境での研究・開発を想定したプログラミング用フォントです。テキストエディタやターミナルエミュレータ、プログラミング言語やマークアップ言語に対する使用に適しています。Inconsolata と Migu 1M の合成、および、プログラミング用フォントとしてのいくつかのチューニングを行う生成スクリプトを配布しています。Inconsolata 作者の Raph Levien 氏、Migu 1M 作者の itouhiro 氏、M+ M Type-1
超上流を学ぼう
真に役に立つ情報システムを開発するためには、システム企画や要件定義といったいわゆる「超上流」のプロセスで、過不足のない正しい「要求」を獲得する必要があります。しかし、情報システムのステークホルダー（利害関係者）から正しい要求を引き出すのは、簡単なことではありません。 そこで、ステークホルダーから正しい要求を引き出し分析するためのツールとして、現在おおいに注目されているのが「BABOK（Business Analysis Body of Knowledge）」です。 BABOKは、非営利団体「IIBA（International Institute of Business Analysis）」が策定した、「BA（ビジネスアナリシス）」の知識体系で、2006年7月にバージョン1.6が，2009年4月にバージョン2.0がリリースされています。2009年12月には、IIBA日本支部が、BABOKバ
テスト駆動開発チートシート - やさしいデスマーチ
TDD（テスト駆動開発）のチートシートを作ってみた。 TDDBCでid:t-wadaさんが話している内容とかテスト駆動開発入門から引っ張ってきています。 ダウンロードはこちらからどうぞ。 PNGイメージ: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.png PDFファイル: http://dl.dropbox.com/u/1393956/tdd_cheatsheet.pdf 追記 印刷・再配布などはご自由にどうぞ。 もし、元データ（OmniGraffle）が欲しいという人は、コメント欄かTwitter経由で教えていただければ差し上げます。 追記２ このチートシートは、OmniGraffleで作りました。他に使えそうなツールとしては、イラレとか。Visioでもたぶん作れると思います。
AgileJapan2011 まとめ - うっかりアジャイルの推進側に回っちゃった人の日記
対会社向け。 SlideShare の検索はほとんど見つからない。GW 前には集まるといいな。 増えてきた！ 東京 アジャイル開発の適切な運用に向けて Agile Development and Contract from IPA at AgileJapan 2011 View more presentations from Kenji Hiranabe IPA 非ウォーターフォール型開発WGの成果発表。大御所から出てくる資料は会社の上層部に効いたりする。 Agile Japan 2011 - Linda Rising さんの基調講演の録画 - kawaguti の日記 (id:wayaguchi) 川口さんの。なんと動画。ふとっぱらだ！ Linda RisingFearless Change at AgileJapan 2011 View more presentations from
スクラムの概要を1分で理解できるイラスト【2018版】
みなさんこんにちは。@ryuzeeです。 アジャイル開発のコーチングやトレーニングでスクラムの全体像を1枚の絵を使って説明することが多いのですが、以前作成したものを最新化したので公開します。 スクラムの本質的な価値やスクラム以外でも日々のプロセスに組み込んだほうが良いこと（テスト自動化や継続的インテグレーション）は含めていません。 あくまでスクラムの概要のみを書いています。 PDF版はこちらにおいておきます。 ※改変なしで引用元併記の上であれば自由に使っていただいて結構です。著作権自体は私に留保します。 内容の誤りや足りない事などがありましたらTwitterなどでお知らせください。 自分のスライドに入れて使うためのパワーポイント版はこちらになります。 著作権表示なしでご利用いただけます（ただしこのファイルを含んだパワーポイントの再配布および販売はできません）。 それでは。 SCRUM BO
4/15 Agile Japan 2011行って来ました！ - モーニングセッション編 - ShiroKappa Blog
有料のカンファレンスに２００名満員御礼の熱さそのままに、多くの方が熱いまとめやレポートをしていただいておりますので、私は相変わらず自分なりの感想を綴ってみたいと思います。 今回はモーニングセッションについて綴ります。 【モーニングセッション】 アジャイル開発の適切な運用に向けて 〜「非ウォーターフォール型開発WG活動報告書」の概要〜 スピーカー：情報処理推進機構(IPA) ソフトウェア・エンジニアリング・センター(SEC) 山下博之氏 公開講演資料：http://goo.gl/F0406 開始早々濃いセッションでした。２０分と時間が短かったのもありスピーカーの方もかなり早口でした。 このセッションで特に印象に残ったのは、アジャイルに必要なスキルについて。 ・ファシリテーションスキル ・イテレーションスキル ・マルチタレントスキル とまとめられていました。 日本人はシャイと言われますが、一度
テスト自動化に関するスライドの紹介
みなさんこんにちは。@ryuzeeです。 SlideShareでテスト自動化に関する良いスライドをみつけたのでご紹介します。 Agile Toolkit http://www.slideshare.net/nverdo/agile-toolkit-mo-conf 参考になる部分は以下の3スライドでしょう。順に説明していきます。 手動テストのコストプロジェクトの初期は以下のような状況です。 テストする項目は少ない手動でテストを完了するのも簡単まだプロダクションでもないし、問題があって影響を受けるのは限定された人だけしかし時間がたつにつれて 手動でのテストにはとても多くの時間がかかるようになる製品が出荷されてしまうと、バグによってとても多くの人が影響を受けることになってしまうという状況に変わっていきます。 右のグラフは手動でテストを行った場合のテスト時間の推移を示していますが、見て分かる通り、
なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド
出張してもどってきたら社内Tracが残念なことになっていた 最近、もともと所属していたチームをはなれて外で開発をしていた。 久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。 （今現在も解決していない） ほかのチームでRedmineを展開してそこそこ上手くいっていたので、 なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。 個人的なメモ。 何がいけなかったのか 個人的に思うところは以下の３点 ・マイルストーンの役割を誰も理解していない ・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない ・求められる機能とTracの機能に乖離があった マイルストーンの役割を誰も理解していない 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて ITS使ってる人には常識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
