JIRA導入

アジャイル開発でよく使用されるJIRAを導入した。

JIRAとは

Atlassianのソフトウェア開発ツール。 チケット管理することで課題、タスク、計画を管理します。アジャイル開発でよく使用されています。

Free版もあるので個人、お試しでも利用可能です。

導入方法

Atlassianにアクセスし、Free版を開始します。アカウント登録、プロジェクト設定終了後にすぐ利用可能です。 www.atlassian.com

ボード

登録した課題の進捗状況を確認する画面です。タスクのみ。エピックやサブタスクは表示されないようです。

ステータスごと列が仕切られています。ステータスは、作業前・進行中・完了がデフォルトで 名称の変更、ステータスの追加も可能です。

列に登録できる上限を設定することもできます。あまり用途が考えられませんが、キャパシティーが超えないように設定する、といった使い方をするそうです。

ロードマップ

ガントチャートです。エピックと関連づいているタスクが表示されます。

課題

チケット（タスク）は課題と呼ばれます。 設定項目は既定の項目を追加することも可能です。

課題タイプは、エピック、タスク、サブタスクがあります。増やすこともできる模様。 それぞれマニュアルには以下の通り説明があります。

エピック課題は、Jira の作業の概要レベルのイニシアチブまたは大規模な単位を表します。ソフトウェア チームの場合、エピックは開発中の新機能を表すことがあります。

標準課題は、通常の業務タスクを表します。Jira において、標準課題は、チーム メンバーが日常的な業務を議論または実行するために使用されます。

サブタスク課題は、チームが標準課題を細分化するのに役立ちます。これは、チームに複数人で作業する必要があるタスクがある、またはチームが作業のスコープや複雑さを過小評価している場合に役立ちます。サブタスクは関連する標準課題とは独立して詳細を記述して見積もれるため、チームがその後、同様の作業をより適切に把握して見積もるために役立ちます。

上記はガイドラインであり、プロジェクトやチームごとに合った定義ができればOKと考えます。

レポート

課題をグラフで可視化します。 デフォルトではメニューにないため、プロジェクト設定－機能でONすることで表示されます。

JavaEE「CDI」について①

今回はJavaEEの機能であるCDIについてです。 使い方というよりは概念的なイメージを理解していくことを目的にします。

CDIとは

Contexts Dependency Injection。 「Contexts」は状況とか環境の意味です。サーバとかオブジェクトなどの状態を示しているのだとお思います。

「Dependency Injection」はDIという略称で馴染みがありますね。「依存性の注入」と訳されます。

依存性の注入

「依存性の注入」って、いまいちわかりづらいですね。 DIについて調べてみると、

• 疎結合に保つことができる
• テストがしやすい
• 開発効率がアップする

などなど。このうち「疎結合に保つ」というところが「依存性の注入」に関係しています。

「依存性の注入」をもう少し詳しく言うと「依存するオブジェクトを外部から何らかの形で注入する」ということになります。

依存するものとは、多くの場合「他のクラス」です。
「他のクラス」に依存されないようにする　→　疎結合

簡単な例で言うと、

public void testA() {
    …
    Sample sample = new Sample();
    …
}

とすると「testA」は「Sample」に依存しています。 「sample」に設定するインスタンスを外部から設定することができれば「testA」は「Sample」への依存度が低くなります。

「外部からの注入」は、DIコンテナからでも、自力でやっても構いません。これを行うのが「DI」の考え方です。

「DI」を機能やフレームワークの意味として言うこともありますが、どちらかというと「設計方針」的なイメージの方が私はしっくりきました。

「DI」に「Contexts」を加えた機能が「CDI」

この「DI」に「Contexts」の「状態」が加わると「依存するオブジェクトの状態」、つまり「ライフサイクルの管理」ができるのが「CDI」ということになります。

CDIでどんなことができる？

CDIのメインはDIだと思いますが、DI以外にもCDIは色んな仕様を定義しています。

• DI機能
• コンポーネント間の連携
• トランザクション管理
• インターセプター
• インスタンスのライフサイクルの管理
• デコレーター
• イベント通知

調べてでてきたものをあげてみませした。半分以上はわかりません。

まとめ

今回はCDIの概念的な意味、特にDIの理解について調べました。 具体的な機能は少しずつ調べていこうと思います。
まずはやっぱり「DI」ですね。 CDIの「DI」について調べていこうと思います。

---

詳細設計書に何を書くべきか

システム開発の工程では必ずと言っていいほど「設計書の作成」があります。

色々な種類の「設計」があるとは思いますが、一般的には「基本設計書」と「詳細設計書」ではないでしょうか。

そして「詳細設計書」にはいつも悩まされます。
どんなことを書くべきか。

なお、ここではアプリケーションの開発、特にビジネスロジック周辺の開発を想定しています。

どんな設計書がある？

私の経験でいうと

• ロジックを文章にしたもの
• クラス図やシーケンス図
• フローチャート
• インプットとアウトプットを示した図（名前がわかない）
• 画面仕様書にロジックを詰め込んだもの

がありました。

このうち「ロジックを文章にしたもの」の割合が最も多かったのですが「これって意味あるの？」っていつも思ってました。

「ロジックを文章にしたもの」はなぜ意味がないか

ロジックはコーディングしながら作り上げていくものだし、文章を書いている時点では正しいかわかりません。

多くのプロジェクトでは「設計書作成→実装」のプロセスを踏むので、結局「設計書作成→実装→設計書修正」みたいなことになります。
「工数が余計にかかる」し「メンテナンス」も追い付きません。

じゃあ本来何を書くべきか、どんな内容があればいいのか考えてみました。

そもそもなぜ必要か？

プログラマーがプログラミングするためのドキュメント。 プログラミングをするために必要な仕様、処理ロジック、SQL、変数などを記載する。

上記は一例です。ちょっと古すぎかも。
ただ「プロぐラミイングをするための」っていうところは今もブレてないと思います。

どんな内容を書くべきか？

個人的には

• 処理の概要
• クラス間の関連
• インプットとアウトプット
• 処理パターン
• 例外一覧

がわかればいいのではと考えています。 ちょっと外部仕様的な観点も入っちゃっているかな。

書いてあることしかできないPGは厳しいのかもしれませんね。オフショアとかでやる場合とか。

開発は新規だけではない

システムは作り終えたら「もう触りません」ということはほぼないと思います。

障害対応なり、機能追加なり、コードは常に変更する可能性があります。
それも特定のメンバではなく誰が変更することになるかわかりません。

そう考えると新規開発だけでなく、障害対応・機能追加の時も約に立つ設計書であるべきではないでしょうか。
分かりづらい設計書だと、結局コードを読むしかない状態に陥ります。

いや、それはある意味正しいと思います。ロジックの隅々まで表現するのは難しいので。

だからこそ「コードを読む」ための助けにもなってほしいのです。

基本設計書がきちっとある前提ではありますが、詳細設計書は上記のような内容でもいいのかなと考えました。

自分の苦手な工程なので、かなり主観が入っていますが(^_^;)

---

マルウエアが侵入した

先日、仕事中に急にアラートメッセージが表示されました。

「ウィルスを検出しました」って。
毎日定期スキャンを行っているのですが、そこで見つかってしまったのです。

こうなるとめんどくさい。
ネットワークを切り離してフルスキャンしろだとか、どこに報告しろだとか仕事になりません。

検出したファイルをネットで調べてみたら「マルウェア」ということがわかりました。

マルウェアって？

マルウェアってとなくイメージはついていましたが、改めて調べてみました。

悪意のあるソフトウェアの総称。ウィルス、ワーム、トロイの木馬など。

あー「マルウェア」の方が上位に位置するものなんですね。
「ウィルスのひとつ」みたいに思ってました。。。

幸い、スキャンで検出後すぐに隔離に成功しました。
今の現場ではウィルスバスターを使っています。

隔離はウィルスとかワームが悪さできないよう、特定の場所に「隔離」するそう。ここでは活動できないようになっており、その後削除したりします。

いまの現場ルールではセキュリティ管理者の指定した場所にアップロードされるんだとか。何者かを調べたりするんでしょうね。

ちなみに「駆除」は感染したファイルからウィルスだけを削除します。元のファイルを復旧するのであまりうまくいかないことが多いのだとか。

どこから侵入したんだ？

ウィルスなりワームなり感染後は色々悪さされることは容易に想像がつきます。
個人情報流出、機密情報流出、パソコンが異常などでしょうか。

ビジネスの場だとユーザに迷惑がかかり、会社間の問題に発展しかねない。
とにかく感染しないにこしたことはないです。

そもそもセキュリティソフト入ってるのになんではいってきたのでしょう？

一般的に感染経路は「メール」、「サイトアスセス」、「外部メディア」などです。

今の現場では外からメールは来ないし、最近外部メディアで新たにインストールとかしないし。

考えられるのは「サイトアスセス」です。
その日も確かにネットは使っていました。使っていましたが（その日は）怪しいサイトにアクセスした覚えはないんです。

技術的な情報を調べたり、お昼休みにニュースを見たり。

で、結局突き止めることはできませんでした。

自分では怪しくないサイトと思っていても、トラップが仕掛けられてるというのは非常に怖いです。

こうなると気をつけようにないので「頼むぜウィルスバスター」となるのだが何故か侵入を許してしまった。

検知できるなら止められるじゃないのって。
ここはちょっと腑に落ちない。

自分でできる対策は？

セキュリティソフト頼りがいいのだが、そうは言っても自分で気をつけられることもあります。

• 対策ソフトを入れる
• ソフトウェアのアップデート
• OSのアップデート
• 極力実績のないサイトにアクセスしない。

うーん、OSのパッチが最新じゃなかったな。。 早速最新にします。

今回は特に問題視されませんでしたが、対処に三時間ぐらいかかるし、何と言っても事故を起こすのが怖いのです。

できる対策はとっおかないと、何かあったときに「ベストは尽くしてたんですが」と言い訳すらできなくなるので気をつけたいですね。

---

「Windows7」のサポート終了時期

ついこの前「Windows XP」のサポート終了話で世間がにぎわっていると思ったら、もう「Windows 7」の終了話がでてきています。（Vistaの時は音沙汰なかったな。。。）

Windows7のサポート終了は2020年1月です。
東京オリンピックの年ですね。

サポート終了問題って、SEにとっては仕事の「機会」にもなるので注目している人も多いのではないでしょうか。

• システムがこれまで通り動くの？
• 見た目は変わらない？
• Officeのバージョンは？帳票大丈夫かな。
• いっそこれを機にシステム再構築しますか。

などなど。OSのバージョンアップに伴った需要が発生します。情シスの人達が騒ぎだします。
サーバOSも含むとなおさらですね。
ちなみに「Windows Server 2008」が同じ時期にサポート終了になります。

当然サポート終了後は「Windows 10」を使用することになりますが、インパクトはどれくらいあるんでしょうか。
私は仕事ではWindows7までしか使ってないので、そろそろ準備しなきゃですね。

---

CDNサービスによるサイト高速化

サイト高速化の手段としてCDNという仕組みがあります。

「爆速すぎて笑う」 表示速度が“異常な”Webサイト「dev.to」 その仕組みは - ITmedia NEWS

以前にも「CDN」のキーワードでニュースを見たことがあり注目していたのですが、どうやら流行りつつあるようです。

CDNとは？（Content Delivery Network）

Webサイトのコンテンツを世界中に配置したキャッシュサーバにキャッシュ。アクセスユーザが最も効率の良いキャッシュサーバを選択するので高速にアクセスできるのだとか。上記記事では「Fasty」という事業者の例でした。

なんか聞いたことあるなーと思い調べると、私が知っているところでいうと「Akamai」がCDN事業者でした。 Web系のエンジニアは聞いたことあるのではないでしょうか。

キャッシュサーバの仕組みは目新しくもないと思いますが、なぜ流行りつつあるか。

これまでキャッシュサーバの課題はリアルタイム性でした。
更新に時間がかかるのでリアルタイム性を求めるサービスには向いていなかったんですね。

ところがキャッシュの更新が「ミリ単位」でできるようになり、この課題を解決しました。

事業者によって違いはあるのかもしれませんが現地味を帯びてますね。「日経電子版」にも導入されています。

注目です。

---

JavaEEをもう少し詳しく②

前回JavaEEは「企業向けシステムを開発するためのフレームワーク」ということでまずはひとつ理解しました。

今回は具体的なJavaEEの機能について調べてみることにします。

JavaEEの主な機能

• Java Servlet
• JSF(Java Server Faces)
• CDI(Contexts and Dependency Injection)
• JSP
• JAX-RS
• EJB
• JMS

などなど。。 私が使ったり聞いたことがあるものを中心に拾いました。

たくさんあります。ひとつひとつ調べるだけでも大変です。

主にサーバサイドで使用する機能です。そのため「Webシステムを開発するための」と言われてるということでしょうか。

ここで大事なのが、これらの機能は実体を示すというよりは「こういう仕様ですよ」を定義しているということです。
そのため、その機能を実現しているフレームワークがまたあったりする。「参照実装」と言ったりするそうです。

ということで今回はJavaEEは
「JavaEEはサーバサイドの開発を行うための機能を定義したもの」
と理解しました。

それぞれの機能の話はまた少しずつ調べていきます。