Jの衝動書き日記

さらりーまんSEの日記でございます。

東京編(後編)

6月24日(日) 東京

東京二日目。今日は最初から参戦。そのため9時20分頃には府中競馬場にいなければならない。なので6時30分起きである。仕事で起きるよりも一時間も早い。でもちゃんと起きれた。やはり早起きはやる気の問題である。

さて、昨日の反省を踏まえて今日は単・複のみの買いである(単のみとしないところがチキンだが)。昼食は少しは豪華にできるといいのだが。

1〜3Rは複がちょこっと取れたぐらいだったが4Rで単勝ゲット。幸先がいい。なのでお昼は昨日より若干豪華にチャーハン650円。

f:id:newWell:20180624114320j:plain

200円高いだけ? 馬鹿言っちゃいけません。200円あれば2つ賭けれます。

で、その後も5・6Rも続けて単勝ゲット。

これは行ける!ということで昼食をプラス。

f:id:newWell:20180624131758j:plain
f:id:newWell:20180624141834j:plain
f:id:newWell:20180624153523j:plain

ホルモン焼きとレモンハイに串カツとアイスコーヒーゼリーを追加。ただレースは続けてあるので移動の合間にちょくちょく足した感じ。

コーヒーゼリーがアイスが甘い分若干苦い。しかしその苦さが後も続くことに・・・。

 

はい。では結果である。

単勝4勝8敗 複勝も同じく4勝8敗。

……惨敗である。残金は5120円。掛け金の42%しか残ってない。まあ、昨日の20%に比べるとだいぶましではあるのだが。

でも5000円もあれば美味いものは食べれる。しかし明らかに敗者めしだ。5000円の敗者めしはないであろう。ということで3000円は次の機会に回すことに。

で、今日の敗者めしは三鷹にあるとり屋ゑび寿でとった。なにゆえ三鷹かというと帰りの電車が座って帰れるからである。

f:id:newWell:20180624181708j:plain
f:id:newWell:20180624182414j:plain
敗者めし 次こそは!

ミックス焼きにセロリの浅漬け勝利のVチキンである。……あ。次こそはと勝利のVチキンの写真で締めるつもりだったのに写真撮り忘れてた……。さ、幸先が悪いなぁ。

では次は7月。

競馬めし始めてみた+東京編(前編)

家の近くには中山競馬場があるのだが行ったことはなかった。ふと興味が湧いてきて行ってみたが結果は負け。でも思ってたよりは負けなかった。だがTV越しでしか見たことがなかった競走馬を目の前で見たくなってきた。

しかし中山で開催されるのは9月。ちょっと待ちきれない。

それならば出向くか。でも出不精なこともあり土日にわざわざ遠出するための理由としてはちょっと弱い。

それならば。

掛けた結果の金額で外食すればいいのではなかろうか。勝てば豪華な夕食・負ければ敗者めし。

うん。これなればいいだろう。そんなわけで始めてみた。月イチの企画である。まあすぐに飽きるかもしれないけど。

あとここでは予想をやるつもりはない(というかできないし)。買い方も基本的には気に入った馬名+パドックで見た姿買い+オッズで適当にというものだ。出向くのが億劫になってしまったらそこが辞め時なのだろう。

6月23日(土)東京

いきなり遠出はハードルが高いのでまずは近場から。でも家から府中本町駅までは十分遠い。府中本町駅の駅名は武蔵野線の終点だから馴染みはなかったがここにも競馬場あったんだ。ついでに言うと総武線での終点といえば三鷹だがここに来るのも始めてだ。

今日は午後からの参戦。先に昼食を済ますことにする。ビールを始めとして寿司やらピザやらいろいろあって目移りするがそれは勝ってからということで。

 

f:id:newWell:20180623114043j:plain

府中競馬場の焼きそば

というわけで焼きそば。450円と安い。あんかけ焼きそば500円も気になったがとりあえずはこれで。

 

 

 

で、結果である。

結論から言おう。残金1600円也。5〜12Rの結果がこれである。全くもって惨敗だった。昼食の画像が焼きそばしかない点で途中経過もお察しであるだろう。

ちなみに馬券の買い方はというと単勝一本勝負という男らしいものではなく複勝・ワイド・三連複というチキン買いにもかかわらずこの有様だ。中山のときは負けとはいえ200円程度だったというのに。……ひょっとしてビギナーズラックでもその有様だったのだろうか。

ワイド・三連複がちっとも当たらなかった。1番人気から3番人気を組み合わせればどれかが当たるだろう。楽勝じゃん。とか思っていたレース前の自分を殴りつけてやりたい。とりあえず競馬二回目のものにはワイドや連複は早すぎたようだ。

というわけで今日は敗者めしと相成った。

グルメクーポンを何故か持っていたので駅下のガストで敗者めし。

f:id:newWell:20180623183236j:plain

ガスト飲み①

f:id:newWell:20180623185143j:plain

ガスト飲み②


侘しい……と書くつもりだったがあれ? 意外といろいろ食べれたな。

生ビールにチキンとモッツァレラのトマトオーブン焼き・コーンのオーブン焼き加えてグラスワインとフィッシュアンドチップス。

クーポンで生ビールが安かったとはいえガスト飲みは意外とありかも。

でも今度は敗者めしではないようにしたい・・・。明日頑張ろう。

【思考実験】広告を必要としない無料サービスの作成

仮想通貨を採掘するツール(マイニングツール)に関する注意喚起がずいぶんと話題になっている。
その是非についてはここでは問わない。
個人的にはマイニングツールを埋め込んだサイトは行儀が悪いとは思っているが。

 

ただ、上記のサイトではマイニングツールの導入に関してある一つの免罪符を与えてしまった。
それは「マイニングツールを設置していることを明示すれば犯罪にはならない」ということである。
なので明示すればOKということだ。

 

と、言うことはである。
ユーザがマイニングツールの存在を認識し、ユーザがサービスを利用する上でそれが使われていることに同意しているならばOKだということではなかろうか。
もちろんユーザが利用するサービスは不法のものではないという前提が付くが。

 

さて、世の中には無料となっているサービス(ゲームもある意味サービスである)がいくつもある。
そしてその無料を支えているものの一つが広告だ。サービスのユーザは広告を見ることで無料でサービスを使えている。
ただ、ここで一点問題がある。
広告の設置者に支払われる報酬はその広告がどれだけClickされたかで決定する(サービス利用時に強制的に表示されるものに関しては表示回数かもしれないが)。
つまりClickされない限りは報酬は発生しない。一方無料サービスのユーザはClickはしなくてもサービスを利用できる。広告が表示されることは義務付けられているが実際にそのサイトに訪問することは義務付けられていないからだ。
なのでサービス提供者はできるだけ広告をClickさせるように手を尽くすことになる。
ユーザは広告がウザいと思いつつそれで無料で使えているのだからと甘んじて受け入れる(もちろんその無料サービスがそこまでして利用する価値があるからだが)。

 

ここであるサービスを考えてみる。
そのサービスは無料で使えるが、その代わりにそのサービスを利用中はマイニングツールのリソースとしてユーザのPCを利用する。
マイニングツールの利用はそのサービス利用に支障をきたさない程度に使う・もしくはそれを調整可能にする。
するとユーザは多少PCのリソース使用度は上がるがサービスを無料で使えることになる。何よりウザい広告はでなくなる。
そしてサービス提供者はサービスが使われている限りは一定の報酬をマイニングツールから得られる。得られる報酬がどれだけになるかは不明だが、少なくとも広告よりは報酬を得られる機会は確実に多くなる。
ユーザのデメリットとしてはPCのスペックをいくら上げてもサービスの利用快適度はそんなに上がらなくなるということだが。……まあ、これは今もあまり変わらないかもしれない。

 

要するにこっそりやるから問題なのであって、ちゃんと明示さえすれば広告が不要なサービスが作れるかもしれない。

 

今回はその対象がマイニングツールであったが、別のものでもよい。
要するにユーザのPCのリソースを一定量提供することを条件にサービスを無料で使えるということができるかもしれないということだ。
現状の無料サービスの対価は広告が多い。そして広告が求めているのはそれに伴うユーザの行動である。
だが、サービスの対価がリソースになった場合どうなるか。求められるのはリソースのみになる。とてもシンプルだ。
もちろんユーザはそのリソース目的を知り同意するのが大前提である。不正な目的に使われて犯罪者にしたてられてはたまらない。

 

東京五輪祝日移動法成立

勢いで書いてみましたネタ。

 

とあるニュースの報道が6/13にありそれがブックマークをやたらと集めていた。
どうやら2020年に開催する東京オリンピックの開会式と閉会式の前後が休日となるらしい。
混雑緩和のためだとか。まあ、さもあらん。休日が増えてラッキーと考えていたのだがどうやら違うらしい。
どうも休日が移動するらしいのだ。海の日(7/20)・山の日(8/11)・体育の日(10/12)が代わりに2020年では消滅するらしい。
まあ、海の日と山の日は同じ月だからまだわかるとして10月の休日が消滅するのが訳がわからない。体育の日だから? かなり苦しい。
体育の日を移動させるぐらいなら一日ぐらい休日増やせばいいのだ。一年限定で一日休日を増やすのがそんなに困難なのだろうか。
~休日がなくなるなら有休とればいいじゃない~……確かにその通りではあるのだが。ちょっと損した気分になる。

 

ただ、ニュースを読んでいておやと思った。法律が参議院を通過したとある。
参議院? あれ?参議院だけで法律成立するんだっけ?
そんなわけはない。衆議院を先に通さねばならない。

で、いつ通過したのか。調べたら5/31だった。
えぇぇ!! 全然知らなかった。そしてこの法案が衆議院で成立したのをあまり知られていなかったようでどの記事もブックマークが録に集まっていない。昨日(6/13)のものは100を越えているというのに。

 

ちなみに法案が成立するまでの報道の経緯はざっと調べると(およそ10分)次のような感じだ。

2017/7/24 法案が大会関係者間で浮上(http://www.sankei.com/tokyo2020/news/170724/tko1707240005-n1.html)
2018/1/24 法案提出の見込み(※コラムなので報道ではない)(https://www.nikkansports.com/sports/column/we-love-sports/news/201801240000097.html)
2018/4/6 海事振興連盟が海の日移動了承(http://www.tokyo-np.co.jp/article/sports/list/201804/CK2018040602000269.html)
2018/4/12 パラリンピック大会推進議員連盟が法案提出を了承 (http://www.sankei.com/politics/news/180412/plt1804120042-n1.html)
2018/4/23 スポーツ議連が法案了承(http://www.sanspo.com/sports/news/20180423/oly18042318350003-n1.html)
2018/5/31 衆議院で法案成立
2018/6/13 参議院で法案成立

 

どうやら去年から案は出ていたらしい。もちろんちっとも知らなかった。話題にもなっていない。7/24のものはまとめがあったがブックマークはほとんどない。

 

それにどうやら休日にも縄張りがあるらしい。
海の日:海事振興連盟(会長・衛藤征士郎衆院議員)
山の日:山の日制定議連(会長・衛藤征士郎衆院議員)
体育の日:スポーツ議連(会長・麻生太郎副総理)
どうやら休日はおいそれとは作れるものじゃないらしい。だったらそれこそ「東京五輪祝日」議連でも作って特別休日でも作ればいいものを……と思わなくもないが。

今日知った時点はまさしく聞いてなかったよ!案件であるのだが、その経緯自体はポツポツと報道されていたわけである。

 

この「聞いてなかったよ!」案件は仕事をしていてよくある。
何度も説明したはずなのにな……と思いつつ渋々と取りなすなんてこともよくある。
だがこうして自分の身で考えるとよくわかった。
しょせん興味の持てないことなんて瞬間風速で忘れていき、重要度に気づいても取り返しのつかないタイミングなので激昂するのだ。
仕事も結局のところは政治なわけである。政治は面倒だし大変だ。

工数のお話

広告が出るようになったので久々に更新。
ふと工数の話題が上がっていたので殴り書いてみる。

qiita.com

概ね同意だけど以下の点は気をつけている。

 

人日のさじ加減

労働時間が8hあったとしても実際に8h費やせることは絶対にないので1人日=8hでは見積もらない。せいぜい1人日6hで見積もる。もし自分がリーダの立場とかになったらせいぜいい1人日=4h。8hで見積もる場合はもう残業前提ということになる。

 

バッファのさじ加減

必要な作業をすべてWBSとして漏れなくダブりなく出せている場合 → 合計工数x1.5
WBSとして出してない・余裕がない場合 → (自分の感覚工数(最善)+自分の感覚工数(最悪)) ÷ 2 x 3
WBSの洗い出しができない場合はたいてい異常系の考慮が漏れているのでx3程度が妥当。ちなみに感覚工数(最悪)はこれぐらいだったら確実にできるだろうという工数。

ただ、自分がリーダの場合は管理者工数の調整が必要になることも。さらに営業が絡むと利益も上乗せされるため実際の工数との乖離に苦慮したりする。

 

工数/人≠工期(期間)

20人日→ひとりで20日なのだからふたりなら10日でやれる! ・・・なんてことはありえないとわかっているのだが計画を立てる立場になるとついついやってしまう。

工期=MAX(メンバーに割り当てるタスクの合計工数) + バッファ日数

バッファ日数はメンバー間のタスクの偏りにより調整する。

例)
工数:60人日
メンバー:3人
一人あたりのタスク量:20人日(ほぼ同等)
工期:30日 → 60/3=20ではない!

工数:60人日
メンバー:2人
タスク量:A:40人日 B:20人日
工期:45日 → 60/2=30ではない!

 

なおメンバー数は同程度の工数のタスクを同時実行可能な数が理想値となる。それ以上のメンバーがいても工期は縮まるところか逆に増える。

データ定義から読み取る仕様  5. 仕様が抜け落ちないようにするための工夫

全体の目次はこちら

5. 仕様が抜け落ちないようにするための工夫

 さて、4章では概要把握をするには概念モデルを見るのが手っ取り早いことを示した。また、設計を詳細に実装していくことで本来持っていた意味を失う可能性があることも示せたと思う。

 では仕様の抜け落ちをできるだけ防ぐにはどうしたらよいのだろうか。その指針をここでは示そう。

 

5.1 E-R図(概念モデル)の工夫

 E-R図は単なる図ではなく複数の情報を埋め込まれた図だ。だから図の持つ意味を正確に表現しないといけない。

必須事項

  • エンティティの独立・従属はしっかりと区別して書く
    • 長方形:独立・角丸長方形:従属である。気分で変えないように。
  • 多重度の記述は最小・最大を意識して書く
    • 0か1か・1か・1以上か。特に多重度に固定値がある場合は正確に記述すること。
  • リレーションシップにはきちんと意味を記述する
  • なるべく論理モデルとは別立てで作成する
  • 論理モデル起因の概念モデル修正はなるべく控える

しておくと便利

  • エンティティがリソース系かイベント系かを区別可能な記述(タグなど)を付けておく
  • エンティティが核・記述・連関エンティティかを区別可能な記述(タグなど)を付けておく

 

 概念モデルと論理モデルを別立てで作成するとメンテナンスが面倒かもしれない。特に論理モデルで修正が入った場合その都度修正するのは確かに億劫だ。

 だがちょっと考えて欲しい。

 概念モデルでは主キーや属性を記述しないため論理モデルの都度反映は本来不要であるはずだ。また、概念モデルは業務中心に考えたものであるため業務が増えない限りはそうそうエンティティが追加になることもない。論理モデルでエンティティが増えたとしても、システムを実装する上で必要となったエンティティの反映は不要であるはずなのだ。

 もし概念モデルに手を加えなければいけないほどの修正があったとしたら、その修正は影響がかなり大きい証拠でもある。その場合はきちんと概念モデルも反映しないといけない。

 また、E-R図を書くときのポイントだがいきなりE-R図を書こうとはしないことだ。業務フロー図や業務定義書からエンティティ候補をある程度抽出し、その関連を考えてから書くとよい。

 ……え? 業務フロー図や業務定義書がないって?

 ……正式なものではなくてもメモ程度のものはあると思う。それすらないのであれば、まずはそれらを作成すべきだ。

 

5.2 E-R図(論理モデル)の工夫

 E-R図のことなので、基本的な注意事項は5.1と同様ではあるが、一応重複する事項も含めて書いておく。

必須事項

  • エンティティの独立・従属はしっかりと区別して書く
    • 長方形:独立・角丸長方形:従属である。気分で変えないように。
  • 多重度の記述は最小・最大を意識して書く
    • 0か1か・1か・1以上か。特に多重度に固定値がある場合は正確に記述すること。
  • リレーションシップにはきちんと意味を記述する
  • 論理モデル上では複合主キーを安易に代替キーで記述しない
    • 定義する場合は、必ず候補キーも明記しておくこと(E-R図で表現する方法はないのでメモで追記する)
  • 特定の条件でのみ設定するような属性がある場合はサブタイプで表現してみる
  • エンティティの持つ属性はなるべく更新タイミングが同一となるもので構成する

しておくと便利

  • エンティティがリソース系かイベント系か区別可能な記述(タグなど)を付けておく
  • エンティティが核・記述・連関エンティティかを区別可能な記述(タグなど)を付けておく
  • 属性の記述はそのエンティティを代表するような重要なものに留める

 特に属性の記述については詳細なものは物理モデルで記述するべきである。もし論理モデル上ですべてを記述する場合はツールで重要な属性を色付けするなどほかの属性と区別しやすくするとよい。重要な属性とは主要業務に関係のある情報やそのエンティティのみにある情報である。

 また、論理モデルを元に物理モデルを作成するときに実装上の理由からエンティティを分離・結合した場合はその対応を論理モデルの方へ残しておくとよい。物理モデルで追加した属性を随時変更する必要はない。だが論理モデルと物理モデル間におけるエンティティの対応付けを怠ると論理モデルを残す意味が半減してしまう。

 

5.3 テーブル定義書の工夫

 残念ながらE-R図を作成しない・もしくは作成してもリバース生成のみで留めるとした場合でもできることはある。だが、本来図で表現するようなことも定義書に書かなくてはいけないために記述量が多くなってしまうのであまりオススメはできない。

必須事項

  • 候補キーがある場合はユニーク制約を付けておく
    • 制約を付けない場合は、候補キーをテーブル定義に明記する
  • 関連があるのに外部制約を付けない場合は関連があることを明記する
  • 特定の条件にのみ成立する関連がある場合はその条件を明記する
    • サブタイプのみが持つ関連が該当する
  • 関連の多重度に下限・上限がはっきりしている場合はそれを明記する

しておくと便利

  • 設計時にエンティティを分類した場合、その分類名をテーブル定義にきちんと残しておく
    • 特にリソース系・イベント系程度は記述しておくと便利
    • 核・記述・連関エンティティも記述しておくとなお良い

 

6. おまけ

 E-R図がとても大事だということは今まで述べてきた通りである。ではそれを書くのに適したツールはなんだろうか。

 オススメしたいツールは「A5:SQL」だ(A5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール)。

 これを用いればE-R図の記法に従った図をきちんと作成できる。サブタイプもふつうに表現可能だ。またIDEF1X記法とIE記法どちらも表現できる。

 表示レベルも変えられる。エンティティ名のみ・主キーのみ・属性という風にレベルを変えた表示ができる。表示するべき属性も指定できたりする。まさしく論理モデルを書くには打ってつけのツールだ。

 E-R図からのDDL自動生成やデータベーススキーマからのE-R図リバース作成もできたりする。作成したE-R図を画像イメージ化もできるし、テーブル定義書の生成もできる。

 しかもフリーで使える。使わなければ勿体無い。正直、これフリーでいいの?という出来なのである。これでドメイン定義までできたらまさしく神ツールだったのだが(ドメイン定義機能もあるにはあるのだが機能としては今ひとつである)。

 唯一の難点としては、サブタイプを表現した場合E-R図からDDLを自動生成したときにテーブルが分離されて作成されることだろうか。きちんとE-R図の物理モデルを別途作れば済む話ではあるのだが、論理モデルとの同期がとれないためその辺は手動管理していく必要がある。

 ちなみに商用ツールの場合はこのあたりの挙動はどうなのだろうか。サブタイプを含むE-R図からDDLを自動生成した場合も同じようにテーブルが分離されるかどうか残念ながらわからない。お高いので触り倒す機会がなかった。

 もう一つは「ERMaster」である(ER Master)。A5:SQLWindows用ツールなのでMacな人には使えない。その点ERMasterはJavaなのでどちらでも使える。

 A5:SQLと同様にE-R図の作成からDDLの自動生成・データベースからのE-R図リバース生成・テーブル定義書の自動生成などができる。残念ながらサブタイプの表現ができないため、どちらかと言うと物理モデル寄りのE-R図作成に適していると思われる。

 またEclipseプラグインであるためちょっと動作は重いのが難点か。

 ところで、時折ExcelでE-R図を書くような現場もあるのだが、これは絶対にやめた方がいい。E-R図の図や線の形状にはそれぞれ意味がある。そのため形状を間違うと意味まで変わってしまうのだが、Excelの場合はE-R図の意味を考えずに図を作るだけなので誤りの元である。意味の間違ったE-R図なんて存在意義がないしバグの元になる。Excelで書くのだけは絶対に辞めておこう。使うとしても下書き程度に留めるべきだ。

データ定義から読み取る仕様 4.4 4.3 + E-R図(概念モデル)

全体の目次はこちら

4.4 4.3 + E-R図(概念モデル)

前提

  • テーブル定義に加えてE-R図(論理モデル)が存在する
  • 論理モデルではサブタイプまでが書かれている
  • 実テーブルをそのままE-R図にしたもの(物理モデル)ではない
  • 概念モデルも存在する

 

4.4.1 概要把握

流れとしては以下のようになる。

  1. エンティティのカテゴリを確認する
  2. エンティティをリソース系とイベント系に分類する
  3. エンティティとリレーションシップを元に業務形態を簡潔に表現する
  4. 概念モデルと論理モデルで登場するエンティティの差分を確認する

 

 次に各手順の目的と作業方法を示す。

 なお、手順1と2における作業の目的と作業方法は4.3と同一ではあるがそのまま記しておく。

 

1. エンティティのカテゴリを確認する

  • 作業の目的
    • システムがデータをどういった観点で分類しているのかを把握する
  • 確認方法
    • E-R図(論理モデル)の定義を確認する。特にカテゴリ付けがない場合はスキップする。

 

2. エンティティをリソース系とイベント系に分類する

  • 作業の目的
    •  リソース系のエンティティよりシステムが扱う対象を把握する
    •  イベント系のエンティティよりシステムが扱う業務種類を把握する
    •  リソース系とイベント系の比率でシステムの傾向を把握する。イベント系が多い場合はそれだけ業務の種類が多いということだし、リソース系が多い場合はリソースの操作・メンテナンスが業務の中心だということがわかる。
  • 分類方法
    • リソース系
      • 人・組織・物・設備・顧客・金などを表すエンティティをリソース系として分類する
    • イベント系
      • 企業活動を構成するアクティビティ(活動)を表すエンティティをイベント系として分類する
      • 「いつ・どこで・だれが・なにを」を保存するためのエンティティが該当する
      • 業務定義一覧があればそれと照らし合わせつつ分類する
      • 通常、E-R図ではリソース系を上部にイベント系を下部に配置する

 

3. エンティティとリレーションシップを元に業務形態を簡潔に表現する

  • 作業の目的
    • システムの主要業務を把握する<
  • 確認方法
    •  エンティティ=名詞・属性=形容詞または修飾子・リレーションシップ=動詞で業務形態を表せる
    •  概念モデルと論理モデルと組み合わせ確認する
    •  このとき概念モデルに登場するエンティティのみ確認すること(概念モデルに登場するエンティティが重要なエンティティであるため)

 

4. 概念モデルと論理モデルで登場するエンティティの差分を確認する

  • 作業の目的
    •  概念モデルに登場する重要なエンティティが論理モデルにてどのように詳細に展開されているかを確認する。
    •  また概念モデルと論理モデルの差分を見ることで業務上必要なエンティティを見分ける。

 

4.4.2 仕様把握

前提

  • 概念モデルに登場するエンティティのみ確認する。

 確認観点と手順については4.3と同一であるためここでは省略する。

 

4.5 まとめ

 概念モデルがない手順4.2と4.3だと各エンティティの定義をチェックして業務系かシステム系かを分類する必要が生じていいた。だが概念モデルがきちんとあればそれをみればいいだけとなる。

 論理モデルがない手順4.2だと業務形態をデータ定義からは把握することができなかった。しかしあれば関連の意味を元に業務形態の概要を知ることができる。

 このようにE-R図はシステムの概要を知るには打ってつけの図なのだ。活用しない手はない。