【アイドレス】6/23データの持ち方説明からの検討【システム4ツール開発班】

黒埼紘 @kurosaki_koh

@yura_yuki @kuromu_mk よくわかんないけど、コピペしまくりコードの面倒くささ、と解釈しました。 コピペしまくり太元編成データの罠、でもよい

結城由羅＠世界忍者国 @yura_yuki

@kurosaki_koh @kuromu_mk コードについては途中でライブラリ化したんで、そこまではなかったんですが、ライブラリに置き換える前のコードが残ったりはしましたですね。 というか、データ管理部が散乱したワークシートで、データ更新とかが基本できないところが面倒だったんですよ。新規追加とかになる。

黒霧 @kuromu_mk

@kurosaki_koh @yura_yuki その上で考えると最優先はデータ管理と計算システムの組み上げ、次点がデータ収集とバリデーションするシステム、ユーザーが自力で登録して管理する認証こみの仕組みは三番手くらいの位置付けと感じた。

黒霧 @kuromu_mk

@yura_yuki @kurosaki_koh 基本集める窓口は一つにして、ごった煮のデータをバリデーション、計算、整理するツールを別途用意しておけばコピペの手間以外は片付きそうなきがする。GAS使えばコピペもいらないかも。

結城由羅＠世界忍者国 @yura_yuki

@kuromu_mk @kurosaki_koh 優先順位はまあ、そんな感じでしょうね。 突撃旅団の２でGoogleフォームになった時は管理部分がワークシートに分散、計算システムをAppsで突貫で作らないといけなかったので死にそうでしたな。 ヴァリデーションはフォームの機能が使えましたが。

黒霧 @kuromu_mk

@yura_yuki @kurosaki_koh んじゃあGASは問い合わせようの仕組みとして、実際計算したりしてくれるAPIサーバーだけ組めば楽になるかなぁ。

黒埼紘 @kurosaki_koh

@kuromu_mk @yura_yuki そうねえ。計算ツール部分はAPI有りの独立したサーバーでというのは、よい設計と思う。 全部Javascriptでクライアント側で処理、はなんか危険な気がする。 それはそれで、サーバー落ちても使える（かも）という利点もあったりするが。

結城由羅＠世界忍者国 @yura_yuki

@kurosaki_koh @kuromu_mk まあ、とりあえずはそんな方針ですかね。 もうちょっと、入力データと出力データ、あと提出形式の詳細が欲しい所ですね。

黒霧 @kuromu_mk

@kurosaki_koh @yura_yuki gitlabで共有してるからsetupのmakefile書いておけばいい気がする。今時ならdockerなりvagrantを用意しとくのが筋なんだろうけど。

黒埼紘 @kurosaki_koh

@yura_yuki @kuromu_mk ですねえ。エントリー窓口（とヴァリデーション）、データベース、計算ツールの３本柱というのは、アイドレスに限らず芝村ゲー集団モノの定番ですし、詳細不明な段階ではこれら定番以上の事はあまり決められない。

結城由羅＠世界忍者国 @yura_yuki

@kurosaki_koh @kuromu_mk いつもの結論だった＜定番以上のことは現状決められない

黒霧 @kuromu_mk

@yura_yuki @kurosaki_koh すり合わせが少し進んだので良かった

黒埼紘 @kurosaki_koh

@kuromu_mk @yura_yuki ちと気になってるところとしては、太元書式みたいなパーサを作る必要があるかどうか、というあたり。 これもルール詳細待ちだけどね。 真面目に作ると面倒な部分。 Ruby ならTreetopで経験積んでるけど、JavaScriptで作った方が再利用性は高いのかなあ、とか。

結城由羅＠世界忍者国 @yura_yuki

@kurosaki_koh @kuromu_mk パーサが必要かどうか、「部品」がどの程度複雑な形式をしてるか、によりますよね～ なんとなし、単純なタグみたいな部品をぽちぽち追加して、アイドレスを組み上げるだけかな～って気もしますけど、まださっぱりわかりませんね～

黒霧 @kuromu_mk

@kurosaki_koh @yura_yuki google formで吸収したいなーそこは。なおjsにはviewの操作、serverへのpush、serverからのget以外はさせるべきじゃない、という思想で僕は使ってる。基本はview機能で、データの取り回しは他の言語の方が圧倒的有利。

黒埼紘 @kurosaki_koh

@kuromu_mk @yura_yuki ふむ。黒霧さんがそう言うなら、JavaScriptの使い所はそれでいいかな。 新規さんに太元書式のようなものを覚えてもらう、というのもしんどい気はする。フォームで済むに越したことはないねえ。 フォームで受け付けた編成班が太元書式のようなものにまとめあげる可能性はあるかも。

結城由羅＠世界忍者国 @yura_yuki

@kuromu_mk @kurosaki_koh 個人的に気になってるのは、既存部品からアイドレスを組み上げるというプロセスが入る場合はフォームでは力不足になるんじゃないかな、と。 （部品群表示、そこからの選択、データ送信、登録は、固定フォームだと可能かどうかちょっとわからない）

黒霧 @kuromu_mk

@yura_yuki @kurosaki_koh parserって結局は入力フォーマットとバリデータを組み合わせたものでしかないので、フォームとバリデートするサーバーに分けた方が綺麗にコード分けられるのよね。フォームを作るコストがparser作るコストより高くないと、労力に見合わないと思う。

黒霧 @kuromu_mk

@yura_yuki @kurosaki_koh 中間書式に落としてもらってからフォームでいいんじゃないかなー。この粒度だと公示ルール次第だけど。

結城由羅＠世界忍者国 @yura_yuki

@kuromu_mk @kurosaki_koh 中間書式だと、受け取ったサーバ側に中間書式のパーサは要るのでは？ Google FormでDBのAPIから取得したjsonデータあたりからform内のselectionを作れると楽なんですけどね。可能かはちょっと調べときますかねー ルール次第ですけど