ワカコ酒の「ぷしゅー」とは違う
生酉元華鳩(きもとはなはと)
Qlik View(Personal版)試してみた2 サンプルとして気象庁からオープンデータを取得する
QlikView、QlikSenseを試してみるために、手っ取り早いデータとして気象庁の情報(オープンデータ)を使ってみることにした。http://www.data.jma.go.jp/gmd/risk/obsdl/index.php から、各地の気象情報をcsvでダウンロードできる。
地図から神奈川を選ぶ。地図上から横浜を選んでみる。(地図上にチェックがつく。)右側で、どんなデータが取られているかの確認ができる。
「項目を選ぶ」をクリックし、データの種類を選ぶ。ここでは、「データの種類」は「日別値」、「過去の平均値との比較オプション」では「平年値も表示」に チェック、「項目」で「気温」タブの「日平均気温」、「降水」タブの「降水量の日合計」、「風」タブの「日平均風速」を選んでみる。「期間を選ぶ」タブで 「連続した期間で表示する」をチェックし、2012/1/1-2014/12/31を選択。表示オプションはデフォルトのままにする。
右側の「CSVファイルをダウンロード」ボタンをクリック。デフォルトで「data.csv」というファイル名でダウンロード、保存できる。
58kb。こんな感じ。H:\HDrive\OpenDatadata2012Yokohama.csv として保存する。一度LibreOfficeで開き、Excel2007形式(拡張子xlsx)で保存しておく。(QlikViewがcsv形式ではだめらしい。)
Qlik View(Personal版)試してみた1 インストール
無料のデータ分析ソフト、QlikView。なんかいろいろと自由にグラフとか書けたり分析できたりするらしい。
公式サイト(http://www.qlik.com/)よりダウンロード。利用者登録が必要。登録後メールでURLが送られてくる。「Download Now」ボタンでダウンロード開始。ダウンロード画面にTutorialもあるので、「Download Tutorial」リンクをクリックし、ついでにダウンロードしておく。
<Documentation and Tutorialインストール>
QlikViewDesktop_DocumentationAndTutorial_Japanese_Setup.exeをダブルクリックでインストール。セットアップタイプは「完全」で。
インストールすると1178ページもあるPDFファイルになる。(うわぁ。)
XEAD Editor(XEAD Driver)試してみたい1 Javaインストール
2015/3/25開催、モデルベースソフトウェア開発コミュニティ勉強会#1で、【「そのまま動作するモデル」としての生産管理システムの実例 渡辺 幸三(わたなべ こうぞう)氏】との講演会があった。(詳しい報告は http://notainu.hateblo.jp/entry/2015/04/25/170411 )
その中で、モデル書けばコード要らないXEADの話が出たので、試してみることにした。
Java8(作者ブログによるとつい最近対応したらしい。http://watanabek.cocolog-nifty.com/blog/2015/04/xeadjava18-dc9b.html 開発者のサイトによるとすごい勢いで更新されている)で動くOSS。
http://homepage2.nifty.com/dbc/xeadDriver.html が本家サイトで、ダウンロードできる。
本家サイトによると【XEAD[zi:d] Driverは、業務システムをはじめとするデータベースシステムの開発に特化したOSSプラットフォームです。同梱の仕様書専用エディタ(XEAD Editor)を用いて「仕様書」を書けば、XEAD Driverがこれを読み込んでシステムを動的に立ち上げます。保守フェーズでも仕様書を修正するだけ。よくある「自動生成ツール」ではないので、コードの再生成もリコンパイルも要りません。(http://homepage2.nifty.com/dbc/xeadDriver.html)】だとか。おー。
インストール方法についてはhttp://homepage2.nifty.com/dbc/xeadDriver.html に記載あり。
jdk-8u45-windows-x64.exe をインストール。
環境変数にC:\Program Files\Java\jdk1.8.0_45\bin追加。コマンドプロンプトでjava -versionと入力して出てくるのを確認する。
http://homepage2.nifty.com/dbc/xeadDriverDownload.html から最新版をダウンロード。
……と思ったら自社ネットワークからはねられてダウンロードできません(泣)
右クリックすると妙に長いURLが出るから「問題あり」扱いなのか?
……GitHubからソースコードダウンロードして実行するしかないのかなぁ……? GitHubはダウンロードできるのかなぁ……。(実はあまりGitHubの使い方知らないのよね……)
Johnnie Walkerらしい2
LOG ZIPANGU 2014 SAUVIGNON BLANC
酸味が少しありアザンブランと近い感じで好み。生ハムがほしくなる味。
Johnnie Walkerらしい1
袋しぼり生原酒 風香
モデルベースソフトウェア開発コミュニティ#1
- 2015/4/25開催、モデルベースソフトウェア開発コミュニティ勉強会#1に参加した。
- connpass告知サイト:http://mbsdcjapan.connpass.com/event/13108/
- ハッシュタグ:#mbsdc_japan
- Twitter : https://twitter.com/mbsdc_japan
- Facebook : https://www.facebook.com/mbsdcjapan
- 次回イベント:5/27 19:00-(予定)
- コミュニティの考え:要求仕様をきちんとモデル化。モデルは処理の対象。モデルベースでコードを作成する手法を試して学ぶことでスキル向上、仲間増やして……
第ゼロ回(キックオフ)のまとめ:
【「実践 UML モデリング」株式会社テクノロジックアート代表取締役長瀬嘉秀氏】
- 「独習UML」他80冊以上の著書があるらしい。
- 「コンポーネントベースのモデリング」:あらかじめ部品化を意識し、システム化範囲を分割し、分割の単位でクラス図を描く。クラス爆発の可能性が低いが、分けるのに失敗すると爆発する。
- CBOP(ビジネスオブジェクト推進協議会)の「コンポーネントモデリング分科会」があり、プロセスの例について議論されている。
- OMGのMDAに対応させ、CIM、PIM、PSM。
- CIM(コンピュータ処理非依存、外部仕様):アクティビティ図を使った業務分析。ユースケ図・非機能要件・画面・シナリオで要求分析。
- PIM(プラットフォーム非依存、内部仕様):オブジェクト図、クラス図で構造分析、相互作用図、ステートマシン図、クラス図で振る舞い分析。
- アーキテクチャ検討、プラットフォーム設計。
- シーケンス図を書いているとクラス図に操作が挿入されていく。Presentation層、ドメイン層、……。
- MVCモデル。マッピング。HTML/JSP、Servlet、JavaClass、DB。PIMとPSM。
【「そのまま動作するモデル」としての生産管理システムの実例 渡辺 幸三(わたなべ こうぞう)氏】
-
業務システム開発における動的制御型MBSDの実践。
-
MBSDには二種類ある。目標が違うため。
-
1)コード生成型。モデルからコードを生成する。コーディングの手間を減らすのが目的。
-
2)動的制御型。モデルをそのまま動作させる。コードそのものを減らす。モデルがそのまま動けばよいよね、と。個々の開発案件でコードを扱うことが非効率、必要悪、という価値観。コード含有量が高ければ負け。コード行数とファンクションポイント。
<<動的制御型MBSD基本テーゼ>>
-
DSLとDSPの準備:DSLは上位ドメイン固有言語。DSPは上位ドメイン固有プラットフォーム(Domain Specific Platform。DSL用のエディタとドライバを擁する開発基盤。)
-
アプリ定義の極小化:処理の類型に基づき、個々のアプリを差分として様式化。処理のパターンを類型。システム定義が信じられないほど小さくなる。生産管理システムを2MB程度に収められたり。従来コードが抱えていた仕様を、ドライバに持たせる。全部パターンとしてドライバにロジックを持たせる。
<<動的制御型MBSDで>>
- 究極のアジャイル型開発。アジャイル=コードを愛している人たち、だが、コードを一行も書かないアジャイルもあり、では。業種業態別リファレンスを起点とするスプリングボード型開発。開発案件ライブラリがまとまっていく。レファレンスモデルが教材として使える。
-
人海戦術が要らなくなる。アジャイル=チーム開発が好き、だが別に孤独でもいいのでは(おひとりさま開発。フルスタックエンジニア+クライアント)。
-
契約単価が上昇する。準委任契約に基づく士業化。フルスタックエンジニアでないとダメ。
-
動的制御型MBSDのためのモデル表現:UMLはコード生成向け。ERD、DFDはPIM、仕様書はPSMとして有効。PSMはそのまま動くもの。仕様書は人だけに理解可能なプログラミング指示書である限り革新が生まれない。仕様書を、人にも機会にも理解可能な「プログラムの在り方を示すモデル」としたい(=そのまま動くモデルとしての仕様書。)
-
XEAD editor(http://homepage2.nifty.com/dbc/)。仕様書の集まり。メニュー仕様書、画面等を階層保存、表示。テーブル仕様書とか機能仕様書とか。パターンが準備されている。実行するとそのまま動く??(XEAD Driver)。コードを生成するのではなくドライバが仕様書を読み込んで起動しているとか。(なんかすごいなぁどこまでできるのかなぁ。http://d.hatena.ne.jp/kurokouji39/20140522 を見る限りMicrosoftSQLServerとはつながる?)
-
質疑応答:テーブルのセキュリティは?→メニュー設計で対応できたりする。(発注担当はxxメニューしか見えない、とか。)ログインした人の所属情報(セッション)とテーブルスクリプトでどうの。
【EclipseCon 2015 レポート(Eclipseにおけるモデルベース開発技術の現状と動向)ビューファイブ LLC代表社員田中 明(たなか あきら)氏】
Eclipse Con 2015 NA Report。NorthAmericaに行ってきた報告。参加者数775名、日本からの参加は田中氏だけだったとか。
EclipseはIDEという認識が主、という感じだが、今はたくさんのプロジェクトがある(https://projects.eclipse.org/search/projects/?keys=)。検索からModeing選ぶと40個くらいも出てくる。Eclipse Working Groupというものがあり、Automotive、Location、Science、IoT、Polarsys(組み込み系)とかもあったり。何をしているか、は2014年のAnnualReportがよい(https://eclipse.org/org/foundation/reports/annual_report.php)。ActiveProjectの数とかCommitterの数とか公開されている。
EclipseConferenceは、Eclipseに関する最新情報を提供する場として年3回開催されている。フランス、北アメリカ、ヨーロッパ。それぞれ過去の情報も見える。
- DSL:Xtextは米国でも適用事例が増えている。
- TextUML。テキスト形式でアクションを含むUML記述を行い、Xtendでコード変換を行いクラウド上で実行するプロジェクト。(Xtextとは別系統。)
- EMF Forms:EMF/EcoreモデルからUI生成。
- PolarSys:SimuLinkとEMFのimport/export。
- Xtext:Pythonスタイルモデル記述(インデント)、新FomatterAPIで表形式モデル。IntellijIDEA対応。GitHubへ移行。(スライド:「THE FUTURE OF Xtext」参照。http://www.slideshare.net/sefftinge/future-of-xtext)BEGIN、END区切り。クラウド上のIDEを作るとか。
- Diagrams, Xtext and UX:ダイアグラムはできるが双方向ができないとか。FXDiagram。(Java FXが使われている。)Show in FXDiagramでEclipseから開く。プラグイン依存関係を表示できたりとか。
- Graphical DSL:Sirius+Xtext、Arduino designer。Siriusのランタイムの上で動き、モデル表示できる(?)。
- UML-RT tool(リアルタイムUML)
- TextUML Toolkit。CloudFire。
- Acceleo:コード生成。
- PolarSys:Massif、Papyrus-RT(UMLツールのRT版。LinkedinのExecutable UML Group参照。)本当にできれば、という印象だとか。
- Capella timelapse。公式サイトに動画とかがあるので雰囲気がつかめる。
- ViewPoint:
【BridgePoint を用いたモデルデバッグと自動生成 ETロボットコンテスト本部審査員 土樋 祐希(つちとい ゆうき)氏】
ETロボコン実行委員会。BridgePoint自体は昔からある。シュラーメラー法:xtUMLの前身。
ETロボコン:ボディは決まっており、プログラムで対決。32kRAM、256kROMをいかに使うか。コースを走ったり、デモさせたり3つの部門がある。http://www.etrobo.jp/2015/
BridgePoint:xtUMLの方法論を取り入れたツール。モデルを記述し、萌えるのまま動作させ、最終的にはモデルをソースコードに変換する。モデルの変換は変換ルールで実施。昨年からOSS。(以前のブログ記事:http://notainu.hateblo.jp/entry/2015/02/09/213712)
開発プロセスとしては2点。1)と2)はMarkingファイルで変換(?)。
モデルはクラス図、ステートマシン図。組み込みでは状態が重要。ステート内のアクションを専用尾アクション言語(抽象度高い)で記述する。アクション言語はいろいろな言語に変換可能で学ぶのはあまり難しくないらしい。
Verifierで、モデルをコンパイルすることなくそのまま実行、モデル検証可能。
モデルとMarkingファイルを入力としてコード生成。モデルは既存の外部コードと接続でき、BridgeとFunctionという仕組みがある。モデルで書いたものがIFとなるFunction、既存のIFを取り込むBridge。
デメリットとしては、モデルの書き方が特殊(継承ポリフォリズムがない)、環境に合わせた変換ルールを用意するのが大変。(メタモデル、プラットフォームなど幅広く知らなければいけない。ただしルールを作る人のみ。ロボコン用にはルールは準備されている。)
メリットはプラットフォームを意識せずコードレビューしなくてよくなる。モデル、変換ルールを再利用しやすい。モデルとコードがかい離しない。
ロボコン用ロボットは二輪で倒立させる。センサを用いて制御するクラス(Balanced robot。)最後にイベントを投げて起動。ボタンが押されるのを待って、ジャイロセンサー誤差補正し、タイマー仕掛ける。……でEclipseで実行の確認して(ステートマシン図が色が数秒ごとに変わったりする)、Cygwinでコンパイルし、USBケーブルでROMで読み込ませ、ロボットが動く、と。
モデルで動作することを学ぶと、どのくらいをモデルで書けばよいのかわかるので、通常の分析、設計にも有効だと感じられる。
モデルベースソフトウェア開発コミュニティ(第ゼロ回) キックオフ ブログ内記事のまとめ
いつかはライオンでもいいにゃ
純米吟醸 幻 (広島の八反錦100%)
いつかは虎にゃ1
佐藤寿一 しぼりたて純米
かなりすっきりして一口目が水のような酒。
のたどらトイレに泣く Part2_8 無事流れた
渓流朝しぼり 出品貯蔵酒 氷冷熟成酒