のたどらトイレに泣く Part2_7 真空すぽすぽ4
chateau les fermenteaux bordeaux 2013
どちらかといえばあっさり系。果実味豊かというか。
イベント「Webクリエータに告ぐ！ ……ツール紹介」
2015/03/15 SHIBUYA★LABU のイベントに参加。HDE社の会場＠渋谷、にて。正式名称「Webクリエイターに告ぐ！？ ツールに頼って余った時間で◯◯しよう！ ～ 注目！制作現場で触っておきたいツール紹介～」
- イベント概要：https://shibuya-labu-pt.doorkeeper.jp/events/21794
- 講師：オフショア開発PMとかやっている、株式会社ネクストの国際事業部、千葉 礼美氏 Twitter@rechiba3
- 講師は酒と女とらーめんが好きらしい。ラーメンブロガーだとか。Webディレクター。http://rechiba3.net/ 後日スライドがUPされるらしい。
【ツールの選定眼を鍛える】
頼りになるツールをどう探すか。ツールを選ぶ際に「頼りになる」を選定の基準に。忙しいのを何とかするために頼りになるツールを探す。目的用途にマッチしており、使う気にさせ、信頼ができるものを。他の人に紹介できるものを。
ツールで置き換えられること：記録、整理、解析。（言った言ってない論。タスク。バグ報告数。誰のタスクか。バグ解析。）話し合いの材料に。人間はコレを外に出した分、頭の容量が減って他にリソースを回せる。人間は人間ができる仕事を。
→チャット、ファイル管理、タスク管理を使うことで、記録・整理・解析をツールで行うことができる。
【チャットツール】
- 選定基準：ログが残る。プロジェクトごとの部屋。サムネイル画像（部屋とかがすぐわかるように。可視性のあるアイコンを）。引用（内部外部。あのときの時間につぶやいたコレ、とか）の機能性。
- 運用ルール：チャット上でファイル受け渡ししない（ファイルの更新の保証がない。ローカルの中に古いものが入ってしまいどれが最新かわからなくなる。ファイル管理ストレージでやりとりするように）、関連タスクのID、URLの明記。話題ごとに決められたチャットルームで発言（未来のあなたのため。いつ死んでもいいように、自分が死んでもプロジェクトが回るように）。サムネ画像登録（すぐ判別できるように）、チャットルームが必要なくなっても消さない（ログを残すため。あるいはエクスポートする。過去のやりとりをさかのぼったり検索したり。）
- ツールの例１：chatwork（http://www.chatwork.com/ja/） いつのつぶやきへの返信かがよく分かるのが魅力的。ただ機能が多すぎて嫌われることも。
- ツールの例２：slack（https://slack.com/） スラックと読む。チャット情報の編集機能で固定のURLとかメモしておけるのが便利。（テストサーバについてとか。）外部引用が優れておりGitHub、Twitterと連携している。GitHubでのコミット情報を流したり、Twitterの特定IDを全部取っておいたり、とか。かなり快適らしい。
【ファイル管理ツール】
- 選定基準：容量の監視、増減ができる。バージョン管理システムとの連携。メンバーによるアクセス権限。所属組織全員が同じものを使える。
- 運用ルール：クライアントとのルールと現場とのルールを定義（クライアントは絶対ルール守らないことを前提として割り切った管理するのも手）、チーム内での命名規約。ディレクトリ構造がツリーになるようにフォルダを作る（社内全員が意識する）。バージョン管理システムが導入できる（Git等）。古いファイルルールを無視しない（できるだけ踏襲して現場感を伝えるように。ただ伝統の継ぎ足しは厳しいので提案してみる）。
- 皆がいろいろな状況の知識を持ち寄ってツールについて議論し、何を選ぶか皆で検討する。
- ツールの例１：Bitbucket（びっとばけっと、と読む）。Version管理との親和性が良い。https://bitbucket.org/ コミットメッセージを記録できるのが便利。メッセージをWebで開くことで他の人がソース見なくても進捗を把握できる。
- ツールの例：SourceTree（https://www.atlassian.com/ja/software/sourcetree/overview）。サーバがフランスにあるのでたまに遅いことがあるとか。（会社がフランス）
【バージョン管理システム】
- SVN、Git（ぎっと、と読む）など。複数あるバージョンの差分を記録。ファイルの変更履歴の記録やバックアップ、修正内容や機能追加を復元、修正することができる。
- 分散型と集中型が存在。SVNとGitを使い分けすると良い。（目的に合わせた管理手段。）
- SVN（Subversion）（http://subversion.apache.org/）：ファイルを同時に編集することがないリソースで使うのに向いている
- Git（http://git-scm.com/）：同時に同じファイルを編集するリソースに向いている。
【タスク管理ツール】
- 選定基準：最低限の登録項目（名称、概要、期限、担当者、ベロシティ）が網羅されているか。作業量の見積もり、記録ができる。現状のステータス（タスクが終わったのか進捗中なのか）。全員が閲覧できる。
- 運用ルール：タスクには必ず担当者を作る。期限切れを放置しない（やりたいこととやることを一緒にしないようなタスクのきりかたをする）。見込み・実動向数の記録（見込みとどう違うかをあとで確認できる）。タスク粒度を細かく。詳細は後ほど、をしない（詳細欄を書くところにすぐ書かないと絶対やらない）。
- TiDD（TicketDrivenDevelopment）：チケット駆動開発。TicketFirst。NoTicket,NoCommit。タスクが発行されることでリソースが動く。チケットが出てから仕事をする。チケットがなければコミットしなくて良い。無駄なリソースが発生しない。（チケットがないのになんか忙しそう……はダメ。）
- ツール例１：Trello（https://trello.com/） 小規模なものに向く。運営の確認とかToDoにすべて発行して、メンバーどうしが何をやっているか等にも使える。アカウントがあればだれでも。背景変えたい場合は課金。個人的に「今日のタスクはコレ」が日報管理に良い。常にChromeにつけっぱなし、で使っている。
- ツール例２：JIRA（有料）（https://www.atlassian.com/ja/software/jira）。インタフェースのラベルを変えられる。Backlog、ToDo、Doing、Done等。レポートの出力がすごい良い。いまどれだけ時間が費やされているか等。検索システムも優れている。公式の英語動画を見るべし。
- ツール例３：producteev（https://www.producteev.com/）（ぷろだくてぃーぶ、と読む。）スピード感が優れている。インタフェースは英語。
【まとめ】
タスクの記録、整理、解析は道具に任せて、コミュニケーション、やるべき仕事に集中できるように。
【質疑応答】
- SubversionとGitの使い分けは？ → Gitは同じファイルを複数で、は向いているが、全員がソースコードを修正することは意外にない。Version管理を触ったことがない人にGitが説明しにくい → 講演者様からご指摘があり修正しました。「Gitは同じファイルを複数で編集するようなことに向いているので、ソースコードファイルの管理がベスト。しかし、稀なことが無い限りは同時に編集をしないデザインカンプやドキュメント等はSVNでいいのでは。」 （……たしかにプログラムソースでも小規模だとよほどのことがないと同じファイルをほかの人と一緒に修正かけることはないですよね）
- チケット管理をエンジニアが守らないんだけどｗ できないものは見ないふりをするとか → 次の次のリリースにはFixしたいからチケット発行する、等。誰かが管理するとか。（増えすぎたり消えない・期限切れの場合。）
- 会社で揃えられるの？ → うちはばらばらだよ。でも揃えようとしている。チャットはchatwork一つ。
【その他】
HDE（会場提供会社）からの紹介。クラウドセキュリティ「HDE one」。一つのアカウントパスワードでの統一的管理。
のたどらトイレに泣く Part2_5 真空すぽすぽ2
eye spy 2013chardonnay。非常に飲みやすくおいしく、万人受けしそうな一本。
Java女子部セミナー「JVMのいろは」日本電信電話株式会社OSSセンタ 久保田祐史氏
- イベント情報：https://javajo.doorkeeper.jp/events/21337
- ハッシュタグ：#javajo
- 講師：久保田祐史氏、@sugarlife。Java歴６年。２年前からOpenJDK読んでいる。都内のほどほどのスイーツ情報を呟いている。Javaはあまり書かないらしい。（JVMはCだから）
後日公開された資料：
ここ（今回のセミナー）ではJVM=HotSpot VM。OpenJDK/OracleJDK。Oracleから落とせるJavaのこと。java Dukeのように実行するところがJavaVMの出番。Java仮想マシン。Javaバイトコードの実行環境。書いたコードがどこでも動くようにするもの。主な機能として、コードを実行するための機能、メモリの管理（プログラマがやらなくていい分、こちらがやらなきゃいけない。ガベッジコレクタとか）。コードを実行するためにはクラスの存在を知り、ロードし、検証（パッケージ情報を識別するとか。ロードしただけで放置ではない）するクラスローダがある。インタプリタ、JITコンパイラが、メソッドの要求する命令、計算を実行する。
- JVM、JRE、JDKの違い？ →とりあえずJDKでOK。JVM、クラスライブラリを合わせたのがJRE（Java Runtime Environment）、それに開発ツール(javac）を含めたのがJDK。最小限だけの場合JREだが、トラブルシューティングのためJDKも入れたほうがよい。客先に入れる場合にはマイナーバージョンも合わせたほうがよい。（Versionをどうやって確認するかも必ず事前に見ておくこと。Linuxの場合にはrpm -qa | grep java。Windowsの場合もスクリーンショットとって送ってもらう。）
- クラスローダとは？ →クラスファイル（.class）を動的にメモリ上にロードする機能。必要な時（たいていは起動した瞬間だが具体的な説明は困難。クラスパスに通すと実行した瞬間に読み込む）にロード。複数あり、親子関係を持つ。Javaで書かれている。
- インタプリタ？ →バイトコード（中間言語）を逐次解釈しながら実行する。OSが直接実行するより遅い。よく使われるのは機械語にして高速化するのがJITコンパイラ。（Just in time。じっと、と読む）実行回数が規定値を超えたもののみコンパイル。（これを超えた、という明確な基準は不明。）
- 開発者が意識するポイントは？ →知りたい人だけ知ってればよい。なんとなくなイメージだけとらえていれば。このレベルで高速化することはほぼない。ただNoClassDefFoundErrorが出たらクラスローダの仕組みを理解するとき。IBM資料（http://www.ibm.com/developerworks/jp/websphere/library/java/j2ee_classloader/index.html）、@ashigeru 氏が作ったSlideShareの資料（http://www.slideshare.net/ashigeru/classloader）がよい。ソースを変えずにデバッグしたい場合（jarだけある）、バイトコートインジェクション。（例：ツールとしてbyteman。）挙動だけ見ることができる。
- JITコンパイル方法を知りたい：JavaDayTokyo2014資料がよい。（http://researcher.watson.ibm.com/researcher/files/jp-ISHIZAKI/PPL_SummerSchool2004_ishizaki.pdf とかかな。）だが、知りたい機会はほぼこない。
- Javaのメモリ構造は？ →HeapとNonHeap（非ヒープ）、JVMは主にCヒープを使う。HeapとNon Heap合わせてHeapと呼ぶことも。HeapはYoung世代、Tenured（Old）世代、非Heapは世代なし（Permanent。JDK8以降はMetaspace）。YonungはさらにEden、Survivor1、Survivor0がある。
- Heapわけの理由は？ →複数のGC（ガベージコレクション）を利用するため。停止時間を短くするために複数ある。YoungがMinor GC、TenuredはMajorGC。アプリケーションがずっと動いていてオブジェクトが不要にならないとTenured。若くてどんどん死ぬものはYoung。MajorGCは大きな空間を見るのでそれに向いているアルゴリズム。範囲広くてしっかり、な感じ。
- OutOfMemoryError（OOMEと略されるらしい！）の原因をどうやって確認する？ →そのときにメモリ周りを意識することに。メモリリークか、メモリ不足か、バグか。（Slideshare oomeで検索すると説明資料が出てくる。http://www.slideshare.net/YujiKubota/javalangoutofmemoryerror-java）まずはOOMEの後にすぐ出るメッセージを確認。Java.heapと書かれているとHeap。リークか不足か。ヒープ使用量をグラフ化して確認する。増えたり減ったりしつつも増えすぎている場合、急にどんと増える場合（アクセスが増えてセッション維持して回収できない場合等）。YoungとOldは、参照があるかどうかの違い。不要になったタイミングでGCで回収される。YoungとOldの違いは、オブジェクトの年齢で、参照され続けてオブジェクトが長生きしていたらYoungからOldへ移動する。参照が無くなったら不要になり、不要になったタイミングでGCで回収される。（脚注：講師に修正ご指摘いただきました。ありがとうございます。）まずEdenに入り、次にSurvivor0に入り（例：Bufferがcloseしたら捨てる、Webアプリでセッション作ってオブジェクトがどんどん増えてブラウザが切られてセッションが終わったら参照も切れてGCがそのタイミングで。（SlideShareでCMS GCで検索すると出てくるスライド参照。GCログの読み方等が書かれている。
http://www.slideshare.net/YujiKubota/concurrent-marksweep-garbage-collection ）
java.lang.OutOfMemoryError #渋谷java
Concurrent Mark-Sweep Garbage Collection #jjug_ccc
- GCを見るには？ →GC Viewer。GCのログを指定して読み込ませてやる。Full GC LineとUsed Heapを表示するとよい。Full GCが発生しても右肩上がりならリークしている。
- いつ見ればよい？ →結合試験あたり。OutOfMemoryErrorが出るか、性能試験のときか、あたりで見ればよい。アプリケーション停止時間が見られるので、10秒とかなっている場合にはメモリ増やすなりチューニングする。（Heapメモリ。OSのメモリではなくHeapだけに関係する。OOMEはCヒープよりむしろHeap。）
- OutOfMemoryErrorとは？ →ExceptionではなくError。一貫性がなく不安定。意図しない動作。情報を取ったらすぐ殺す。HeapDumpを取るオプションがある。CoreDumpを取るオプションもある。メッセージ種別によって原因がいくつかある。Java heap space（－Xmxで指定した以上のヒープを利用しようとした場合。ログからの調査。GCログはloggc、PrintGCDetailsで確認。ヒープダンプから分析。PrintClassHistogramでクラスがどれだけとっているか。←HeapStatusで全部見える）、GC overhead limit exceeded（GCが頻発して時間的な閾値を超えた。98%。GCががんばっても回収間に合わない。メモリ不足で落ちる。OracleJVMでよく発生）、unable to create new native thread（スレッド作成上限。procfsのVmHWM、free等で確認。Xssかメモリ増設。JMX、jconsole、jstack等でスレッド数を確認。OSでスレッド数を変えることもできるが責任はとれない）、could not allocae Unicode String（String作るときに入らない。JDK6ではPermGem、7以降はHeapを増やす、とりあえずString縮める）、PermGen space（設定値の変更する。JVMロード総クラスサイズの見積もりミス。付加試験を行い、HeapStatsかGCログで最大サイズ測定。PrintGCDetailsで表示できる）……。
- 自分たちが作っていないクラスが増えている場合？ →JVMのバグの可能性も疑える。
- コードをどう直すべき？ →ぐぐる。
【HeapStats】
障害が起こった時に障害解析したいが、分析の前準備が煩雑で、障害の再現待ちとか手作業での解析とかで時間がかかるが、HeapStatsを使うことでログを常時収集しつつ、メモリリークの予知検知し、SNMPトラップで流せる。5%以下の低オーバヘッドで常時収集。
インストールはrpm（中身が一部アセンブラなのでWindowsは動かない）。Javaの起動オプションを一つ追加でOK。実行中のJavaプロセスに設定することも可能。オブジェクトの参照関係を表示できる。（フレームワークのことも見える。）
AnalyzerはSWINGからJavaFXへ。より直感的になる予定。OSSとして公開済み（詳細は http://icedtea.classpath.org/wiki/HeapStats/jp）。CodeZineに解説記事がある。
知らないなんてもったいない！ 障害発生の原因を洗い出すOSSのJavaVM解析支援ツール「HeapStats」を使ってみよう （1/5）：CodeZine
【参考】
以前のHeapStatsに関するセミナーについて：
JavaOne 2014 報告会「HeapStats の発表と出展を通して見えた JavaOne2014」高雄 慎二氏 - のた犬のうまい猫めし
のたどらトイレに泣く Part2_4 真空すぽすぽ
猫が真空式パイプクリーナーについて調べてきた。三栄水栓、PR8700-L。近所の大きめのホームセンターで入手。ほかにも同様のものがあるが、なんとなくいろいろなところの評価がよさそうだったので、これで。
「Javaプログラミングをスッキリ学ぶための10のコツ」セミナー
「スッキリわかるJava入門第2版」、「スッキリわかるJava入門実践編第2版」出版記念セミナー。岡田大輔氏（日本オラクルOracleUniversityビジネス推進部。Java関連資格・研修企画推進）、中山清喬氏（フレアリンク代表取締役）（スッキリ……の著者）。中山氏が主にしゃべり、時々岡田氏にふる感じで話が進む。
- http://www.impress.co.jp/newsrelease/2015/02/20150210-01.html
- ハッシュタグ：#sukkirijava
- スライドはSlideShareで公開あり
【Java学習のかべパターンと解決方法】
- 学び始める不安。文系。簡単ではなさそう。→挫折して失うものを具体的に想像する。オブジェクト指向は文系理系関係ない。簡単に見えるものが簡単とは限らない。有用かが大事。
- 学習開始直後で、環境構築、エラー。→SaaS、オールインワンIDEの活用。Eclipse、NetBeans、IntelJ等。NetBeansだと入れるとすぐ日本語になるので初心者に優しいらしい。（私はEclipse日本語化せず使う派。）中山氏はvi派らしい。vi用のvラッパーがEclipseにあるとか。エラーで動かない場合には「写経」（はじめのみ。コピペから少しずつ変えてみると良い。コンパイルエラーを確認する。わからなけれがググる。）→（って、このレベルの聞きに来る人が写経って通じるのか？）
- 学習中のかべ。急に難しくなる。→一日一章計画はNG。難所にリソース重点的に投入。難所をしっかりフォロー。
- 難しい原因と対策：複雑なのはゆっくり繰り返し、混乱するのは混乱のもと確認、教えにくい場合は教材講師選定。言葉で伝えにくいものは体験で（？）
- 複雑な部分：配列参照、クラスパス（複数クラスファイル）、継承時コンストラクタ。（インスタンス多重構造と構築順序、暗黙の親、デフォルトコンストラクタ。）参照型、メソッド、クラスとインスタンス、thisやsuper、参照代入可能性。
- 教えにくいの：参照、オブジェクト、抽象クラスとインタフェース、多態性、関数オブジェクトの概念。初学者や小規模コードでメリットを実感しにくい部分。
- 現場と学んだこととのかべ。→慣れる。現と知識以外の知識。
- Javaの今：2年周期で新しくなっており、先まで何が入るかは明らかにされている。Googleでチュートリアル（入門）検索されているのはぶっちぎり一位で約24%（次はPHPで11%）。（Androidのせい？らしい。）企業利用率も一位Java、二位VB.NET（そうなの？？？）。JavaDayTokyoが2015/4/8＠東京フォーラムがあるので、さらに詳しいこと知りたい場合はこちらへ。（http://www.oracle.co.jp/jdt2015/）
- 一線で戦う武器（言語）をいくつ持てるか。中山氏の場合、汎用としてJava（Play、JEE）、短期決戦用にRuby（Rails）、Client、SPA用にJavaScript（jQuery/Ext）、TEX（出版言語として）。武器数制約を考えるとJavaは優位。（デバイス、作れるものなどの面で。）岡田氏はJava（Oracleの社員だからｗ）。ClientとしてはJavaScriptも併用。
- 何を目標に学べば良い？→成人学習には「必要性、得意意識、興味」のどれかが必要。短期目標（２週間、１ヶ月とか）としては次々達成していく達成感とリズム（自己肯定感）、長期目標としては将来達成する大きな価値を考える。（ビジョンに近い感じの。）自信を持つには資格などの第三者評価も有用。
- 資格：Oracleが行っており世界共通の資格。海外でも有用（へー）。ITSSスキル標準と合わせ、Bronzeは0、Silverは1、Goldは2、その上に3。昔は試験範囲が広く受かりにくかったが、今は細分化して受けやすくなったらしい。Bronzeは新人研修やったら取れるレベル。スッキリシリーズ入門＋実践で、SilverからGoldの途中くらいまでカバー。（Goldは若干マニアックな部分が含まれているため。）試験対策としては黒本（徹底攻略Java SE 7 Silver問題集 http://www.amazon.co.jp/%E5%BE%B9%E5%BA%95%E6%94%BB%E7%95%A5Java-Silver%E5%95%8F%E9%A1%8C%E9%9B%86-1Z0-803-IT%E3%83%97%E3%83%AD-IT%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%8B%E3%82%A2%E3%81%AE%E3%81%9F%E3%82%81%E3%81%AE%E5%BE%B9%E5%BA%95%E6%94%BB%E7%95%A5/dp/484433610X/ref=pd_bxgy_b_img_z とか）で。
- 効率よく学ぶには？→「成長が金や時間を生む」人は効果な研修も効率が良い。（急速に成長させることで利益がちゃっちゃと出る場合。ただし研修には当たり外れあり。）（スッキリ入門編は一週間程度を目安。）Web独学は茨の道。（概念、広い範囲。）一般的な人向けには市販書での勉強がバランス良い。書籍はコレを選び、周辺情報をつけていくのが良い。Webもホットやすごいのもあるが、古いものもあり初めての人はそれが選別できない。取捨選択ができないうちは何かによりそって（研修、本）、で。
- 入門者に教えられない→知ってると使えるが違うように、使えると教えられるも別の能力。壁を超えるための定石がある。訓練が必要。（トレーニング方法もある。）教えるための意識は技術者と真逆。
- ＊＊＊トップダウン、ボトムアップのメリットをうまく利用する。全体がこんなにたくさんある、と思ってしまうと不安（トップダウン）になるが、終わりが見えない不安（ボトムアップ）もある。入門者向けとしてはボトムアップで小さな達成感を繰り返すのが良いが、研修テキストだとトップダウンが多い。（学習ゴールがあり全体が見えているため。）どっちかではなく組み合わせる。ボトムアップだと、次へ行く前に動機づけする。
- ＊＊＊ルールから説明と具体例から説明、も同様にメリットをうまく利用する。例えば、の例から像を結びやすい人もいるし（人による）、確実に原則を伝えられるルールベースが良いことも。学び手との相性を見つつ。
- 入門者向け解説パターン：少しずつ（学び、動かし、少しずつしか見せない（見ると不安・混乱。ただある程度割り切って隠さないと、受け手がわかりにくくなる。解説に矛盾が出てくることもあるので説明順番が難しい。正しいことを話していない罪悪感も）、デフォルメ（簡略化。単純化。導き手の能力が問われる）、題材選び（学び手がよく知り、興味がある題材を。勉強自体に興味が無い人にたいしてどうするか。新人に対してだと業務のイメージがないので、業務に寄せるか、それ以外のものに興味をもたせるか、が難しい）。→導き手としての勇気（学びての成長のために隠す（高度な知識や用語を飲み込み、厳密に不正確でなく、高尚ではない題材を選ぶ勇気。周り（知っている人）から見て怒られないか。ただこれができず技術者メンタリティから離れられないとダメ。
- 導き方は？→カリスマ型（背中を見せて）、エスコート型（手を取って一人ひとりの目を見て。その人にとってわかりやすいのはなにか個別に対応）。素敵な学びの経験を持つと導き手に近くなれる。今後導き手スキルは重要。
【スッキリ本の中の人】
- 著者中山氏の他、国本氏（ServletJSP講師）、飯田氏（SQL担当）。イラスト高田氏（ドイツ在住）、DTPにSeaGrape氏（？）、編集石塚氏、片元氏、玉巻氏（編集長）。他にも営業、デスク等。
- 著者はTeXで仮組みしつつ執筆。miyabilink.jpという会社につとめている人たちが頑張る話（サイトは実在。）このサイトや中山氏のブログにもなんか色々あるらしい。
【質疑応答】
- 年配（経験者）どうすれば？→全体研修より個別のほうがいいかも。バックグラウンドが多種多様だと議論が発散したり。一日の研修中一時間をバックグラウンド確認に使ったりもするｗ
- 教えるときに、先に高度なことを見せることによって基礎的なところに合点がいくこともあるのでは？→情報量を見せないことが手法としては多いが、納得されないことも。受け手が高度なものをすっと受け入れることもある。教える側が選択を判断する。学び手のタイプによって変えたり。前提知識がない人には最初から、知識があったり好奇心が高い人には実力１００に１２０あたりを与えてみるとか。（焚きつける。より高みを目指させる。）
のたどらトイレに泣く Part2_2 100円すぽすぽ
吹き出しの文字書き間違えた。どら猫の語尾はにゃー、のた犬の語尾はぬー、にしていたのに。
すぽすぽ、正式名称はラバーカップ。すっぽんとかかぽかぽとか人によって呼び方が違う。
のたどらトイレに泣く Part2_1 今度は詰まった
Ariki CHARDONNAY 「アリキ・シャルドネは輝きのある淡い麦わら色が特徴。洋ナシやパイナップル、アカシアの花などのフローラルな香りが感じられます。フレッシュな果実味に爽やかな柑橘系の風味が印象的です。鶏肉料理などと非常によく合います。」
すっきりで飲みやすく、料理に合わせやすいというのかあまり個性がない感じ。
BridgePoint、xtUMLでExecutable UMLしたい 1 ダウンロード、インストール、ユースケース図
「モデルベースソフトウェア開発コミュニティキックオフ」（2015/02/07）で話題になっていた、「最近OSS化されたUML描画＆コード生成できる」らしいBridgePoint、試してみた。
【BridgePointに関する情報リンク（2015/2/9時点）】
- http://www.mentorg.co.jp/products/sm/bridgepoint/index.html （公式情報。2012年依頼の取り組みを完了し、BridgePointのすべてのソースコードをOSS公開。Editor、Verifier、Model Compilerあり。「「xtUML Editorは、実行可能なUMLモデルを作成するための業界最高のツールと言えるでしょう。市場の他のUMLツールと較べて、開発作業が非常に簡単になります。」だそう。）
- http://www.mentorg.co.jp/products/sm/news/2013/130219.html （ニュースサイトによる説明。）
- http://monoist.atmarkit.co.jp/mn/articles/1106/08/news002.html （富士ゼロックスによるロボットの取り組みでの使用例。BridgePointでソフトウェアが生成されるまでの図あり。てっとり早く概要をつかみやすい。2ページめに、作成した分析クラス図とかあり。「2日間、アフレル（http://www.afrel.co.jp/）の久保秋真氏によるBridgePoint講習会（ロボコン活動事務局企画）」を受けてBridgePointを覚えたとか。研修には「BridgePointでロボットを走行させる骨組み」が準備されているとか。クラス図に漢字が含まれているとエラー。作成したモデルは「Verifierを使用して動作させ、状態やアクションがうまく定義されているかを確認。3ページめに、WBS（Work Breakdown Structure）も公開されている。）
- http://www.toppers.jp/docs/education/BridgePointSozeX002.pdf（全30ページの「鹿威し」開発の資料。TOPPERS/JSP カーネルを利用し、かつ、MDA技術としてExecutable UMLのの概念を適用し、CASE ツールにはBridgePoint 6.1D（Project Technology 社）を使用し、モデルをコードに変換するツールとして、同じProject Technology 社のモデルコンパイラ（MC-3020 v3.3）を使用した開発例。MDAの概要とか、UML各種図のサンプルとかあり。2004年と多少古めだが、UMLの貴重な実用例としてもよさげな資料。「MDA によるシステム開発は、機能要求による仕様を表現する分析モデル(PIM（Platform Independent Model）＝プラットフォーム独立モデル：実装技術非依存)を作成し、非機能要求を考慮した設計モデル(PSM(Platform Specific Model)＝プラットフォーム固有モデル：実装技術依存)へ変換（マッピング）した後コードを生成する」。コード生成にはCygwin利用。make。原本へのリンクは「http://www.toppers.jp/edu-shishi.html」）
【ダウンロード＆インストール】
公式サイト（http://xtuml.org/）のDownloadsより、「Additional Downloads」へ。Installersの、「BridgePoint for Windows（4.2.0、476MB）」をクリックしダウンロード。（Linux版もあり。）
exeをダブルクリックでインストール実行。
「BridgePoint with Eclipse」、「BridgePoint」を選べるが、まぁなんか簡単そうなのでEclipseつきの方を。
デフォルトのインストール先が「C:\MentorGraphics\BridgePoint」だったので、「D:\MentorGraphics\BridgePoint」として、インストールディレクトリ作っておく。そして次へ進んでいきインストール開始。途中でMicrosoft Visual C++2005がどうのと出てくるが特に問題なく進んでいく。
D:\MentorGraphics\BridgePoint\eclipse_extensions\BridgePoint\eclipse\plugins\com.mentor.nucleus.bp.doc_4.2.0\ReleaseNotes\HTML\ReleaseNotes.htm にReleaseNotes.htmがあるようで、勝手にブラウザで開いた。
インストール終了。デスクトップのショートカットか（インストール時に作るかどうか聞かれる）D:\MentorGraphics\BridgePoint\eclipse\Launcher.batで起動できるとのこと。
確かに何かできている。とりあえずダブルクリック。
濃い水色の何か立ち上がり、Eclipseっぽく、「Workspace Launcher」の指定画面になるので、「D:\MentorGraphics\workspace」にしておく。
おー、何か起動しました。とりあえず「Quick Start」で。「BridgePoint UML Introduction」をまずはクリックしろとか書かれているのでクリックすると、ヘルプが起動したｗ
見ていてもよくわからないので、ExampleのGPS Watchを選択してみる。Eclipseのプロジェクトっぽいものが起動。「Use Cases」をクリックすると、ユースケース図が起動した。おー。
【ユースケースいじってみよう】
とりあえずユースケースいじってみる。サンプルを使って。
- 矢印とかユースケースは、右側にある「Use Case」を開くとGenerization、Include、Extendとか出てくるので、クリックして元図形をクリックして、そのまま後図形まで引張り、後図形の上で離すとつながる。
- ズームは、右側にある「Zoom Tool」で、通常クリックすると拡大、Shift押しつつクリックすると縮小。（あるいはツールバーの虫眼鏡。こちらが簡単かｗ）
- ユースケースを書こうとするとデフォルトで「Unnamed Use Case」になるが、既に同じものがあると作られないので、テストの時には1とか適当につけておくとOK。
- 日本語も使えるようだ。
次回はソースコード出力とかやってみるか。
