サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
szk-takanori.hatenablog.com
photo: http://www.flickr.com/photos/zzpza/ Java6がEOLとなったこともあり、コンパイルバージョンもJava7以降を指定するようになったので、標準的に利用するMavenのカバレッジプラグインを見直しています。 Javaのカバレッジツールとして、今のところ有名なものとしては、以下のものがあります。 Cobertura JaCoCo Coberturaは、Javaのカバレッジツールとしては情報量も実績も多くあります。私も、これまではCoberturaを使っていたのですが、Java7を利用するようになってからは、いろいろとエラーが発生するようになってしまいました。 JaCoCoは、情報量は少ないのですが、別のカバレッジツールであるEmmaを置き換えるためのカバレッジライブラリとして、EclEmma(Emmaを利用したEclipseプラグイン)の開発チ
今日は、いろいろなところで、新しいスーツを着た新入社員を見かけました。 当然ながら、ウチの会社でも入社式があり、新しい社員が入ってきました。 本日が社会人最初の日、ということで、一緒にランチに行ったのですが、そこで伝えたのが、 『仕事は楽しいモノ』 という話。 #彼らの頭に残っているかどうかは、分かりませんがw 周りから良く聞こえて来る話で、社会人になると「大変だ」とか「自由が無くなる」とか、最初からネガティブな感じ満載な人がいる。 バイトなどで、楽しく仕事の経験をしてきた人でも、そのように言う人は多い。 サークルと部活の違い、みたないモノかもしれないが、サークルでちょっとやるぐらいなら楽しいけど、部活で本格的にやるとしたら大変なので嫌になる、ってことかな、と思っている。 でも、それって悲しいことだよね。 途中で、会社(場合によっては仕事自体)を変える人もいるけど、それでも人生40年は仕事
先日、Googleのバグ予測アルゴリズムを実装した「bugspots」が公開されました。 ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開 - Publickey 上記ツールは、Gitのリポジトリで管理されているソースのみが対象となっています。 ただ、OSSの開発ならいざ知らず、実際の開発業務では、まだまだSVNの利用も多いことでしょう。 そこで、SVN(Subversion)のリポジトリで管理さ
昨日のエントリーに引き続き、このエントリーは「Software Test & Quality Advent Calendar 2011」における12/19分として書いています。 今日は、少しばかりアカデミックな話。 でも、うまく活用すると、品質改善のための強い武器になることでしょう! 循環的複雑度とは? まずは、今回のタイトルにも書いている「循環的複雑度(Cyclomatic Complexity)」というメトリクスの説明から。 循環的複雑度は、Thomas McCabe 氏が開発したものであり、簡単に言うと、コードの複雑性を数値化したものです。 ソースコードの一部の循環的複雑度は、ソースコード内の線形独立な経路の数である。実際、if文やfor文のような分岐点のないソースコードの場合、その複雑度は 1 であり、そのコードには1つの経路しかない。コードに1つのif文が含まれていれば、コードに
このエントリーは「Software Test & Quality Advent Calendar 2011」における12/18分として書いています。 12/17は @NoriyukiMizuno さんによる 「ソフトウェアテストの勉強会。1年目。」 というエントリでした。 今回は、以前から感じている矛盾について、私なりの考えをまとめたものです。 特に、マネージャーや経営層と呼ばれる人に読んでもらいたいと思っているのですが、このブログの読者層を、考えると、あまり多くはなさそうなので、以下に示す問題について、悩んでいる/苦しんでいるような人から、うまく伝われば良いと思っています。 矛盾する問題 私は、SEPG(Software Engineering Process Group)という役割上、いろいろなソフトウェア開発のプロジェクトや組織に関わってきました。 絶対数で言えば、そんなに多くはない
「Software Test & Quality Advent Calendar 2011」の初日エントリーとして、書きます! テスト/品質系のエンジニアも、今や、テストや品質のことだけを知っているだけでは、幸せにはなれない時代となってきています。 プログラムは書けなくても、身に付けておくと良いと思っている技術をまとめてみました。 ※注 今回記述した内容は、以下のような私のドメインに偏ったモノになっています。 ミッションクリティカル/エンタープライズ系 Java/.NET 他のドメインでは異なる部分や他の標準的なツールがあれば、コメントを頂ければと思います。 バージョン管理/課題管理 今や、必須のスキルと言えるでしょう。 バージョン管理(SCM/VCS/DVCS)としては、 集中型のSubversion(SVN) 分散型のGit/Mercurial などが有名ですね。 分散型の場合は、各エ
少し前になりますが、2011/09/19に、Twitterから、分散リアルタイム処理フレームワーク「Storm」がオープンソース化されて公開されました。 最近は、Hadoopの効果により、BigDataへの注目度が高まっていますが、Hadoopが領分とするバッチ処理から、よりリアルタイム処理へのニーズが高まってきているように思います。 Stormは、BigDataに対してリアルタイムの処理を可能にするフレームワーク。 Hadoopと比較されることがありますが、個人的には、それぞれ用途が違うと思っているので、比較することにあまり意味はなく、特性に応じて使い分けることが重要だと思います。 Stormの特性は、以下のような点。 非常に広範囲のユースケース メッセージ処理、ストリーム処理、データストリーム上の継続的なクエリ実行・クライアントへの結果配信、同時並行で行う対話形式での検索回答(分散RP
5/27(金)に行われた、CloudStack勉強会へ参加してきました。 前日まで10人以上のキャンセル待ち状態だったけど、急に参加できなくなった人も多かったみたいで、補欠から参加者枠内に、無事入ることができました。 CloudStackは少し前までは知らなかったのですが、OpenStackを調べていたところから、つい最近知りました。 日本では、IDCフロンティアがクラウド基盤に採用したこともあり、注目度が高くなっているようですね。 CloudStackを使ってみよう! – 荒井 康宏(オープンクラウドキャンパス/CloudStackユーザ会) 最初は、CloudStackの概要。主な特徴は以下のようなところ。 Cloud.com社がオープンソースとして公開しているIaaS型クラウド基盤 リッチな管理GUIが標準で装備。 実装はJava。 ロードバランサやファイヤーフォールもある。 KVM
Windows Serverでリモートコマンドを実行する必要があって、「サーバなんだから簡単にできるだろう」と思っていたら、結構手こずりました。 忘れない内に、簡単にメモ。 今回、実現したかったのは、以下の条件を満たすリモート処理。 WindowsServer間で実行 リモートのマシンで実行ユーザを指定可能 ASP.NETから実行 同期実行 検討 or 検証したのは、以下の方法。 AT or SCHTASKS コマンド 概要 タスクスケジューラに登録して、コマンドを実行する。 結果:× 非同期にしかできないため、不採用。 WinRM 2.0 + PowerShell 2.0 概要 SOAPベースの通信で、リモートでコマンドを実行する。 Windows2008には標準でインストールされているが、Windows2003Serverの場合は、以下からダウンロードしてインストールすれば利用できる。
昨日、NoSQL Afternoon in Japan に参加してきましたが、スピーカの皆さんが、早速、発表スライドを公開してくれているので、どこいったか分からなくなる前にまとめておきます。 Hibari(Joe Norton) http://www.slideshare.net/geminimobile/hibari-presentation-at-nosql-afternoon-in-japan-on-nov-12010 Okuyama(Takahiro Iwase) http://www.slideshare.net/okuyamaoo/20101101-okuyama Cassandra(Nate McCall) https://docs.google.com/present/view?id=dg8xwrcw_999f25bqnsf ROMA(Muga Nishizawa) 現時点
「要件や仕様が正しく伝わっているか?」ということを把握するのは難しい、と感じます。 自分は当たり前に思っていても、相手はそうでない 打ち合わせで説明したつもりが、相手には意図した通り伝わっていなかった 仕様書はレビューしたけど、理解が違っていることに、受入になってから気付いた などなど、問題の事例を挙げたら、キリがないでしょう。 要件定義のやり方や、レビューのやり方で、ある程度は改善できるモノの、大抵の場合、問題に気付くのは試験や受入段階になってから。 それがプロジェクトの遅延や失敗に繋がることにもなります。 アジャイルなら、早期に問題に気付ける、というのはあるかもしれませんが、それでも手戻りが多ければ、イテレーションはうまく回らなくなるでしょう。 そのような状況に対し、質問表(Q&A表)を分析すると、プロジェクトの傾向が良く分かると感じ出しています。 現在、こんな感じで、質問表の分析を行
以前に、以下の記事を書きました。 進捗管理は「遅れ」か「残り」か これは、今までのやり方を少し変えるだけで、プロジェクトマネジメントの効果を向上させられる良い例でしょう。 ソフトウェア開発プロセスの中では、同様のことが言えるケースがたくさんあると思っていますが、私がこれまでに気付いたノウハウをまとめてみたいと思います。 今回は、まず、レビューについて。 レビューは、大抵のベンダー/SIerでは実施されていると思います。 レビューの目的は、上流工程における不具合の除去、要件の明確化などだと思いますが、なかなか効果が上がらないと感じている人は多いのではないでしょうか? レビューのやり方については、議論されることも多いですが、そもそもレビューだけで問題を解決しようというのに、無理があると感じています。 そのため、私は、設計工程の最初で「設計検討会」を行うようにしています。 これは、 要件は十分に
バージョン管理ツールは、「集中型」と「分散型」に分類できますが、OSSのバージョン管理ツールには以下のようなものがあります。 集中型 CVS、SVN 分散型 Git、Mecruial、Bazaar 最近は、分散型のツールへの注目が高くなってきていますが、「実際の開発の現場でも普及するか?」というと、あまり普及するとは思わない。 OSSの開発コミュニティなど、ある程度スキルが高い開発者が集まる開発では、ブランチ管理が簡単といった分散型の効果が活きてくると思うのですが、実案件の開発現場となると、残念ながら、必ずしもそのような開発者だけではない。 数人程度の小規模プロジェクトならまだしも、大規模プロジェクトになると、レベルもバラバラな人が集まることは必至です。 そのようなプロジェクトでは、できるだけブランチは避けた方が、間違いなく混乱が少ない。 少し前のマーチン・ファウラー氏の記事ですが、バージ
JavaのWebアプリ開発では、Strutsの登場以来、様々なフレームワークが誕生してきましたが、最近の動向はどうなんでしょうね? 群雄割拠、乱立状態で、良く分からん・・・ まあ、「どれが最適なフレームワークか?」なんてことは、目的・用途によっていくらでも変わるので、あまり意味のない議論だと思いますが、何が主流なのかぐらいは知っておきたいですね。 そこで、情報がないかなぁと調べてみたら、以下のサイトを見つけました。 Comparison of web application frameworks 機能比較があって、分かりやすい。 継続して、メンテナンスされている様子。 Javaだけでなく、Perl、PHP、Python、Ruby、ColdFusion、ASP.NETなんかのフレームワークについても書かれている。 10 Best Java Web Development Framework
4/25(日)から仕事で中国に出張に行っていたのですが、その間に、当社のJavaコーディング規約が公開されました。 このコーディング規約は、開発者自身の経験、および、最近のJavaの動向を踏まえ、 現場で本当に役に立つノウハウをまとめたものです。 そのため、Eclipseで自動でフォーマットできるような簡単なスタイルの規約については 記述を省略し、より重要となるコーディングテクニックや考え方について記述しています。 Javaコーディング規約/WEBワークショップ Acroquest Technology 株式会社 コーディング規約を提示されても、内容が古いことが多い フォーマット的なルールは、Eclipseの設定ルールがあれば十分 という想いから、今回、私から社内に相談を持ちかけ、公開に至りました。 内容についても、単にコードの書き方のルールをまとめるだけでなく、 コーディングテクニックや
IPAから、定量的品質管理を実践するためのガイドラインが公開されていました。 続 定量的品質予測のススメ−定量的品質管理実践ガイド 2010/04/28までは、パブリックコメント募集中のため、PDFがダウンロードできますが、冒頭に以下のような記述があります。 本書の内容には、現場での定量的管理が実践できるように、企業での実践ノウハウを体系化し、定量的管理の導入での阻害要因とその対策を示すとともに、特に難しいプロジェクト上流工程の定量的品質管理方法の考え方を整理ました。また、定量的管理や要件定義・設計工程での品質予測のアプローチや事例を補完することで現場でも実践ができように解説しています。 情報処理推進機構:ソフトウェアエンジニアリング 上記にある通り、具体例と共に実践ノウハウが詰まった内容になっています。 全体の構成としては、以下の二部に分かれています。 第一編 定量的品質管理に一歩を踏み
Eclipseから、Windowsのエクスプローラーを開くプラグインは地味に便利。 以前は、以下の3つがありました。 Open External Eclipse Platform Extensions Easy Explorer 個人的には、コマンドプロンプトも開ける「Eclipse Platform Extensions」を使っていたのですが、Eclipse3.5になってから使えなくなってしまったので、乗り換えを検討。 しかしながら、 「Open External」はリンクが死んでおり、ダウンロードできず、 「Easy Explorer」は、更新サイトで公開されているモノはVer1.0.1までと古く、最新Ver1.0.4は、SourceForgeからダウンロードして、手動でインストールする必要があります。 そこで、最近のプラグインをいろいろ探してみたところ、他にもプラグインがありました。
問題点を指摘するだけで「どうすれば良いか」「どうなったら良いのか」、OKを出さない人の品質分析には価値がないと感じます。 それだけか、そのような人の指摘に応えるために、無駄に時間だけが取られるため、マイナスの効果と言えるかもしれません。 ここ数年、「なぜなぜ分析」「カイゼン」という言葉が流行ったせいか、その名の基に、形式的な指摘・分析を求める人が増えたような気がします。 具体的に言えば、OKを出さない人は、品質分析をした結果の文章だけしか見ず、その文章の内容にだけ指摘をします。 肝心の仕様書やソースコードは見ないのです。 その結果、本当に品質を満たしているのか、という本質的な議論にならず、文章の書き方だけの議論になってしまいがち。 これでは、意味がない。 「悪魔の証明」という言葉がありますが、バグがないことを証明するのは、不可能と言えます。 当然、品質を保証するために、バグがないこと(正確
ITPro : 「プロジェクトの失敗につながる九つの要因に注意」、NTTデータの岩本副社長 対象プロジェクトが新規顧客からの受注であること 新システムの要件が「現行どおり」とされていること 新技術や経験のない処理方式を採用していること IT企業と顧客との間で一括請負契約を結んでいること IT企業のプロジェクト原価率が95%以上であること 開発期間が6カ月以内といった短期プロジェクトであること プロジェクトマネジャが過去に似たようなシステムを開発した経験がないこと 受注したIT企業が下請け企業に仕事の90%以上を回していること 顧客の要件定義力に問題があること 当たっていると思います。 でも、これにひとつも当てはまらないプロジェクトなんて、世の中にいったいどれだけあるのでしょうか・・・
久しぶりに記事を書くなぁ。 しばらく忙しかったので、サボってました・・・ そしたら、年が明けてしまったよ。 さて、話は変わって、私はSEPGのリーダとして、いろいろなプロジェクトの進捗を見ることが常です。 そのような中で、 「進捗は何日(もしくは、何人日)遅れ?」 と聞くことは多い。 これは、顧客からも、そのような進捗報告を求められることが多いし、WBS線表では、遅れ日数が進捗を把握する対象となるため。 でも、進捗は、遅れだけ管理していても回復しない、というのが私の感覚。 遅れだけ見ていると、遅れが拡大していることには気づきにくい。 「タスクAは、3日遅れ」という進捗状況ならば、そのタスクは3日経てば完了しているはずだが、多くの場合は完了するまでに3日以上かかる。 そのような場合、「タスクAは、あとどれだけかかかるの?」という質問をすると、3日遅れであっても「5日ぐらい」という回答になるこ
Googleトレンドで、課題トラッキングシステムのTracとRedmineの比較がされていますが、日本ではRedmineがTracに追いついた状況になっているようです(世界全体で見ると、Tracの方が圧倒的に多いようですが)。 プログラマの思索 : Redmineが日本で急上昇している Heretic Programmer : Redmineが日本で急上昇している 「では、バージョン管理ツールはどうなの?」と思ったので、調べてみました*1。 【すべての国】 CVSが多い!?と思ったら、これは米国でCVSというドラックストアがあるようで、そのトレンドが含まれている様子。 バージョン管理ツールのCVSのトレンドが不明なため、ハッキリとは分からないのですが、やはり、CVSとSVNが多そうですね。 また、2009年は、Gitが大きく伸びており、一時期は、SVNと同程度の盛り上がりを見せています。G
ソースコードのメトリクスツールのひとつに、JavaNCSSがあります。JavaNCSSでは、以下の2つの指標を用いて、複雑性を分析します。 NCSS(Non Commenting Source Statements) コメント行を除く行数 CCN(Cyclomatic complexity Number(MaCabe Metric)) if,for,while,case,catch などの条件文の数 Maven2でレポートを出力する場合は、pom.xmlの定義を以下のように指定します。 <reporting> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>javancss-maven-plugin</artifactId> <version>2.0-beta-2</version> </plugin>
InfoQにて、ソフトウェア・エンジニアリングにおける「計測と制御」を振り返る、トム・デマルコの記事が紹介されていました。 InfoQ : デマルコ、ソフトウエアエンジニアリングの40年間を振り返る ※上記では、「メトリクス」が「マトリックス」と誤訳されている点に注意 元になっているのは、IEEEソフトウエア誌の記事であり、PDFとして公開されています。 『Software Engineering: An Idea Whose Time Has Come and Gone?』 この内容は、衝撃的。 「計測できないものは制御できない」というのは、デマルコの有名な格言であり、ソフトウェアエンジニアリングに、多大な影響を与えてきたモノですが、上記の記事では、それを覆し、「計測と制御」が実際の開発を妨げているのではないか、という考えが書かれています。 デマルコは、「計測と制御」よりも重要なモノとし
去年あたりから、オンラインでレビューを行える、オープンソースのシステムが増えてきました。 ReviewBoard VMWareの開発で利用されている、ということで、一躍有名になったレビューシステム。Pythonで開発されている。 デモ:http://demo.review-board.org/account/login/?next_page=/dashboard/ Rietveld Googleのソースレビューシステム「Mondrian」のオープンソース版。Pythonで開発されているが、Google App Engine上で動作させる仕様になっている。 デモ:http://codereview.appspot.com/ 宍道湖 Rietveldを参考にし、Ruby on Railsで開発されたレビューシステム。インタフェース/機能は、Rietveldとほぼ同じ。 デモ:http://is
ソフトウェア開発では、レビューにて、より上位の工程で欠陥を発見することの重要性は、周知のことでしょう。 しかしながら、レビューを効果的に実施するのは、なかなか難しいと感じるところです。 レビューにおける指摘が、フォーマットや誤字・脱字に関してのものが多く、品質への寄与が低い レビューそのものに時間がかかるため、頻繁に実施しにくい。 スキルのあるレビューアは、大抵多忙であり、レビューしてもらえない。 レビューをするタイミングが遅く、修正や水平展開に手間がかかる。 レビューで見逃した欠陥は、テストが完了しないと分からない。 今月は、Think ITで、レビューに関する連載がいくつも公開されています。まだ、全て読んではいないのですが、プロセス定義、定量化、技法、教育等、いろいろな観点で書かれているので、参考になりそうですね。 記事の一覧を、載せておきます。 インスペクションは誰が行うべきか 第1
YUI(Yahoo! UI Library)から、Chartライブラリがリリースされました。 棒グラフ(縦/横) 折れ線グラフ 円グラフ 積み上げ棒グラフ(縦/横) など、基本的なグラフは一通り揃っているようです(動作には、Flash Player が必要となります)。 デモを見る限りでは、比較的簡単なコードでグラフを描画できていますね。 Javaにおけるグラフ表示と言えば、JFreeChartが有名ですが、サーバ側でゴリゴリな実装が必要です。そのため、私自身はあまり好きではなかったのですが、JavaScriptのグラフ表示ライブラリの場合、十数行程度でもグラフが描画できるものが多く、さらに、Ajaxなどでデータ転送量も少なくできるため、今後はこちらの方が利用シーンが多くなっていくような気がします。 また、以前に、グラフ表示のライブラリを調査したことがあるのですが、そのときの情報を以下にメ
上記のWorkflowEditorPluginでグリッド表示をするために、jQuery Grid Pluginを使っています。 グリッドを表示するだけのJavaScriptライブラリは多く見かけたのですが、データの編集まで行えるので、このプラグインを採用しました。 今回は、一部の機能しか使っていないのですが、ページングや階層グリッドの表示/編集など、かなり高機能です。 デモページで、サンプルも豊富に公開されているので、このライブラリを使えば、リッチなグリッドが簡単に実装できます。
以前に公開したWorkflowEditorPluginをバージョンアップしました。 今回のバージョンアップで、以下の2つのモードで編集できるようにしました。 Grid Mode Text Mode Grid Mode を使えば、ビジュアルに確認することができるので、直観的にワークフローをカスタマイズできると思います。 Tracのワークフローは、チケットに対する操作と、それに伴うステータスの変更を定義するのですが、基本的な使い方は、以下の通り。 操作の追加 「追加」ボタンを押下すると、入力フォームが表示されるので、追加したい操作を入力します。 操作の変更 変更したい操作を選択し、「変更」ボタンを押下すると、編集フォームが表示されるので、必要な内容を変更します。 操作の削除 変更したい操作を選択し、「削除」ボタンを押下すると、確認フォームが表示されるので、そのままOKしてください。 ステータス
そういえば、今日のJaSSTのパネルディスカッション(ディスカッションの内容は、「テスト技法からテストメソドロジへの進化を目指して」)で、西 康晴 先生が、「テストでもデザインパターンみたいなものがあると良い」という旨の話をしていたのですが、これはその通りだと思います。 設計においては、設計技法だけでなく、「GoFのデザインパターン」「PofEAA」といった、パターンが多く存在します。パターン自体が重要ではないとは思うのですが、パターンはベストプラクティスであり、それを適切に利用することができれば、設計品質も向上するでしょう。 テストについては、いろいろな技法はありますが、設計におけるパターンのようなものがない。私が知っているものは、「xUnit Test patterns」ぐらい。 「同値分割」「境界値」といった基本的な技法を使っている人は多いと思いますが、「直交表」「デシジョンテーブル
次のページ
このページを最初にブックマークしてみませんか?
『現場のためのソフトウェア開発プロセス - たかのり日記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く