  |
はてなキーワード: RDBとは
前のゲームはテキストファイルで管理してましたがRDBでやるなら、たぶん項目がひとつずつ増える事が多かったので、わざわざ別テーブルにせずに、alter tableをしてたと思います。
RDBを検討した際にテーブル分割などを考えましたが、アップデートで仕様がAになるかBになるかわからない時点で正規化は無理だと断念したのを思い出しました。
作り直すのは途中で何度も考えましたが僕の性格では全部消して作り直すのは非常に難しいように感じます。
作り直せる人ってすごいですね。思い切りが大事なんでしょうか。。。
最初の質問を見たときから普通にidでjoinしてるだけじゃないのって思った
RDBを使って作ってあって、新しいtableが参照したいテーブルのidを持つようにしておけばjoinで全部の要素を持った大きなテーブルがあるかのように扱えるよね。
気ままにそういう運用をしてきたらjoinによるオーバーヘッドがばかにならなくなってきたり、テーブル間の関係が複雑になりすぎて訳が分からなくなってくると思うので、そういう時はいったん開発を止めてリファクタリングするべきだろうね。
高校生です。寝る前に面白いゲームを思い付いたのでどうやって作ろうか考えていたらこんな時間になってしまいました。
沢山のモンスターが出てきて、それを集める要素があるのですが、このモンスターのデータをどう管理するのが良いのか、さっぱりわかりません。
識者の方、お力を貸して下さい。
相談内容を簡単に言うと「仕様が固まっていないゲームのモンスターのデータをどう管理するか」です。
まず、ゲームは小さく作りたいので、モンスターのデータも最小限になるのですが、もしヒットしたらどんどん要素を追加したいのです。
最初はモンスターの数も100ぐらいですが、ゲームの寿命を伸ばしたいので、数千ぐらいまで増やせるのが理想です。
そして、ここが肝心なのですが、ユーザーの反応を見ながら仕様を変えたいので、どんなデータが必要になるのかは、究極的にはサービスが終了する時までわからない、という事です。
年の離れた兄に相談したら「それって昔流行ったパズドラみたいだね」と言われました。話を聞くと確かにそんな感じがします。パズドラも最初から今の形が全て決まっていたとはとても思えませんでした。
(合成とか覚醒スキルとかプラスなどなど、どうみてもあとで思い付きで増えた要素があるように思えます)
なので、この質問はパズドラぐらい大ヒットさせたいという野望があるゲームのモンスターデータを最初期にどう設計するか？と言い換えることもできるのかもしれません。
以前に似たゲームを作った時に困ったのは、例えば
みたいにデータがあるとすると、あとでモンスターを進化させようとして、進化先id という項目を付け足したり、そもそもid っているの？表の上から順番に何個目かってのをid にしたら良くない？と思ってid を削除したり、
などとやっているうちに、コードがぐちゃぐちゃになりました。
どんな追加要素がきても柔軟に対応できて、コードがぐちゃぐちゃにならないようにするにはどうすれば良いのでしょうか？
モンスターを進化させる素材(モンスター自体が素材になる事もあり得る)なんかはモンスターデータと同じものとして管理するのが良いのか、別のものとして管理するのが良いのかもわかりません。
この件⇒ https://togetter.com/li/1452558
ユニケージはbashのパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理（だいたいプログラム1本の処理内容がメインフレームのCOBOLのそれと同じくSQLクエリ1個に相当する）で、同形式によるマスタとトランザクションファイル（RDBMS内部のredoログに相当）を使う（データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバーが複数存在するデータの場合どう扱うかは知らない）
開発と更新は早いんだけど参照が（テキストファイルなので）インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう
おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージで実装されていないかもしれないけど、しかし根幹に上記のような手作りのデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルをマージしてインポートすることになる
追記：トランザクションファイルのマスタへのマージは営業時間後の日次バッチとかでやるはず
システムを止めている間も店舗が運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない
追記：テキストファイルに対するインデクスをつくって行頭へのシークの高速化をすること自体はもちろん一般的には可能だけど、ユニケージの方法論だとそれをする標準的な方法はないはず。ユニケージはRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合（SQLのUPDATE相当）当然行頭のバイト位置が変更した行以降ですべてずれてしまう可能性があるのでインデクスの更新がひどく非効率になる
追記：文章下手ですみません。ユニケージの良いところはRDBMSの実装の基礎を理解できるところ（これはDate先生の教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識はちゃんとした教科書で補う必要がある）、アプリケーション実装技術について横断的な理解ができるところだと思います（USP研究所のシェルスクリプトマガジンには実際勉強になりそうな記事が多い）自分はユニケージへの移行案件を生き残れなかったクチなので。。
追記：Tsukubaiは好きになれませんでした。
SQL、JavaScript 、Excel VBA 、VB.NET、C#、Java。前者ほど触ってる期間が長い。SQLとJavaScriptが1年半くらい、Javaは参考書一冊読んだくらい。
Webで言うとフロントはAngularが少し分かる。サーバーはExpressが少し分かる。
RDBはテーブル15個くらいの社内向けWebシステムを一人で組んで現在半年以上運用中。今はテーブル40個くらいのシステム組んでるところ。
LinuxはUbuntuなら少し分かるけど、Docker周りは手を出したことがない。AWSとかGCPとかも分からない。
実務経験は無いに等しい。独学とプライベートの開発だけでこれまでやって来た。
できれば茨城県南だとありがたい。誰か雇って下さい。
外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか？
外部キー貼らなかったことによって、俺はこんな被害だしたぜっての是非教えてほしい。
すぐに思いついたケースは
とかを思いついたがこんなケースで合ってるのか？こんなケースより間違った外部キーの使い方したほうが家に帰れなくなるケースのほうが多いと思うぞ。間違った使い方をしていて、システムが太ってくるとこんなケースが出てくる。
特に下2つは害悪で、SQLアンチパターンをコピペして、「おまえらw外部キー嫌いはアンチパターンだぞwww」ってやるのもいいけど、同じくらい間違った使い方を注意喚起したほうがいいと思うよ。DB識者のなかでは「そんなの常識w」かもしれないが何もしらない初心者が真似をしてお家に帰れなくなるのは辛くないか？
そんな経験していると、DB初心者は「せや！ユーザテーブルに退会フラグか論理削除フラグ持ったろwww うはw俺天才www」とかなって今度は削除フラグ持つなおじさんが出てくるぞ。しまいにはこれですよ。
http://b.hatena.ne.jp/entry/s/qiita.com/ponkotuy/items/6049388d564fb4385f4e
初心者どうしたらいいんでしょうね(*_*) 是非、DB識者には明るい未来を示して欲しいね。
俺？俺はAndroidのエンジニアでSQLiteは使わないから関係ないね。
RDB初心者の俺が恐れ多くも案を出すと、FKを作成する前に、そのテーブルの性質を予測することが大事なんじゃないかね？大量に発生するログデータなのか、大事なトランザクションデータなのか、第2正規化しただけのただの情報テーブルなのか。大事なトランザクションデータだったら親が削除された時にどこにどうやって退避するか。大量のログデータだったら、親が削除される時どうアプローチするか。とか恐れ多くも予測するね。
ちなみに外部キーないからER図出せないってのはそれはツールの作りであって、FK制約とは関係ないんじゃないの。バリデーション(外部キー)はセキュリティ対策(ER図を作成する)の為、実装するってのと個人的に同じことだと思っている。
日経xTECHの元記事を読んでもCOBOLの特徴があんまり伝わってこない感じだし、かといってそれをディスってもしょうがないので、書いてみた。
https://anond.hatelabo.jp/20190205192741
COBOLは本質的にはDSLなんだけど、一見汎用プログラミング言語に見えてしまってRubyやPythonなんかと比較するのが誤解のもとではあると思う。今の人でも知ってそうなCOBOLに似ている言語はたぶんSQLで、データを処理するための専用言語。ただ、SQLは頑張ればすごく複雑なこともできるパワフルな言語で、だからこそ現代でも生き延びているわけだけど、COBOLはわりとシンプルなデータ処理を想定している感じ。
SQLだけでアプリケーションを作れないのは触ったことある人なら誰でもわかると思う。普通はJavaやRubyで全体の流れを記述してデータベース入出力をSQLで書く。COBOLもそんな感じで、全体の流れをJCLやShellスクリプト、あるいはJP1のような運用管理ソフトで書く。SQLの1個の処理に相当するのがCOBOLのコンパイル単位で、それごとにソースファイルが分割される。ひとつのソースファイルに2個以上の処理を書くこともできるけど普通はしない。ここまで理解すると古いCOBOLに1ファイル内のすべての処理に影響するグローバル変数しかないのや、今のCOBOLにコンパイル単位をまたぐ真のグローバル変数がないのも、それほどクリティカルではないことがわかると思う。もし、本当に複数の処理にまたがる値が必要なら、データベースに格納してしまえばいいんだし。
で、SQLでいうところのデータベースに相当するのがCOBOLではデータファイル。sedやawkでテキストファイルやCSVファイルを行ごとに処理するのとちょっと似てるけど、COBOLの場合は固定長ファイルという点が違う。改行文字は入ってなくて、たとえば150バイトごとに次のレコードみたいな形式。これの1レコードごとに何月何日何時に〇〇という商品を□□円で売ったとか書いてあるのが典型的なデータの内容。それを集計して今日は〇〇が何個売れて売上がどれだけあったとか、出金合計がいくらで入金合計がいくらで、みたいな財務諸表を作ったり。SQLと同じように税率なんかが書いてあるマスタデータと、日々の売り上げが書いてあるトランザクションデータがあって、突き合わせたりということもする。こういう集計処理だからUIはなくて、夜中に自動起動するようなバッチプログラムが主な使われ方。（混乱するから余談だけど、今のCOBOLはSQLを使って普通のRDBにもアクセスできる。ただ使い方としては、RDB→ファイル処理→ファイル処理→ファイル処理→ファイル処理→ファイル処理→RDBみたいに、最初と最後だけみたいなのが普通）
入出力がファイルだから今の感覚で考えるとアクセスは遅い。でもメリットもあって、1回に1行しかメモリに乗せないからどんな巨大なデータでも時間さえかければ処理できる。それこそ国民ひとりひとりの年金データとかね。あと、途中でバグや不正データで止まってもデータを失うのは最小限で済むので復旧が比較的楽だったり。
データベースの話に戻ると、テーブル定義はどこに書いてあるかというとデータファイル側ではなくてCOBOLプログラム側、というのがSQLと一番違うところかも。つまり、このデータファイルの構造はこれこれこうなっていると想定して読みます、とソースコードに自分で書く。当然実際のデータ構造がそれと違ってたらおかしくなる。
まあそんな感じで80年代くらいに会計処理をする目的だったら悪い言語ではなかったので、銀行や官公庁とか、電力水道ガスといったライフラインを扱う大企業がこぞって導入して今に至る感じ。普通の大企業は途中でSunとかに置き換えてその後Linuxやクラウドにさらに置き換えたりしたけど、最初に作ったシステムが大きければ大きいほど、重要であれば重要であるほど現代的な環境に置き換えられないというのが今の課題。
同意。
ロック処理とか甘いしサイズ制限も2GBだしANSI SQLに一部対応してないしで、Webサービスのバックエンドに向かないのは間違いないが、さりとて5万行程度のテーブルを捌けない程無能なRDBでもない。
複数テーブルでもちゃんと外部参照設定して第3正規化するくらいは普通にできる。複数テーブルJoinしたりサブクエリ書いたりもできる。
元の発言した人は、ちゃんとAccessを使ったことがあるのか疑問である。
ただ、Excelよりも便利なのは確実だが、WordとExcelくらいしか使えない人も多いので、ほかの人とデータ共有するのであれば、Excelのままでもいいかな。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 86 | 15570 | 181.0 | 63 |
| 01 | 41 | 2954 | 72.0 | 40 |
| 02 | 15 | 2460 | 164.0 | 60 |
| 03 | 16 | 5067 | 316.7 | 38 |
| 04 | 19 | 3688 | 194.1 | 63 |
| 05 | 5 | 417 | 83.4 | 22 |
| 06 | 6 | 487 | 81.2 | 39.5 |
| 07 | 20 | 1497 | 74.9 | 35 |
| 08 | 34 | 5674 | 166.9 | 50 |
| 09 | 66 | 6624 | 100.4 | 35.5 |
| 10 | 92 | 9985 | 108.5 | 46 |
| 11 | 117 | 10209 | 87.3 | 50 |
| 12 | 116 | 13997 | 120.7 | 35.5 |
| 13 | 110 | 5844 | 53.1 | 32 |
| 14 | 142 | 12684 | 89.3 | 39 |
| 15 | 145 | 9551 | 65.9 | 33 |
| 16 | 148 | 9011 | 60.9 | 34 |
| 17 | 75 | 6396 | 85.3 | 35 |
| 18 | 161 | 23682 | 147.1 | 30 |
| 19 | 137 | 12711 | 92.8 | 42 |
| 20 | 75 | 10183 | 135.8 | 55 |
| 21 | 114 | 10938 | 95.9 | 35.5 |
| 22 | 110 | 10636 | 96.7 | 41 |
| 23 | 137 | 8276 | 60.4 | 32 |
| 1日 | 1987 | 198541 | 99.9 | 39 |
人(179), 自分(134), 話(86), 問題(81), 今(76), 日本(64), 仕事(64), 増田(60), 意味(58), 女(58), 男(55), 必要(50), ー(47), 人間(46), 気(45), 感じ(45), 前(44), 好き(43), 理由(41), 場合(40), あと(39), 相手(38), 子供(37), 関係(36), 存在(35), 金(34), 安倍(33), 他(32), 最近(31), 世界(31), 無理(31), 女性(29), 気持ち(28), 会社(28), 事実(28), 社会(27), 状況(27), レベル(26), しない(26), マイノリティ(26), 結婚(25), ネット(25), 普通(25), 完全(25), 別(25), ただ(25), 子ども(25), じゃなくて(25), 今日(24), 結局(24), 生活(24), 頭(24), 時間(23), 大学(23), 理解(23), 検索(23), 記事(23), 意見(23), お金(22), 絶対(22), 中卒(22), 親(22), 最初(22), ダメ(21), 個人(21), 自体(21), 作品(21), 言葉(21), 昔(20), 正直(20), 確か(20), 目(20), バカ(20), 件(20), 違い(19), 友達(19), 可能性(19), 人生(19), 認識(19), 扱い(19), 嫌(19), 全部(19), 障害者(19), 馬鹿(19), 内容(19), 一番(18), 毎日(18), 差別(18), 手(18), 主張(18), 逆(18), 権力(18), 批判(18), 情報(17), 場所(17), オタク(17), 普段(17), 世の中(17), サービス(17), 結果(16), たくさん(16), 顔(16), html(16), 嫌い(16), 全て(16), 質問(16), マジョリティ(16), 先(16), 現実(16), 平成(16), 家(16), 表現(16), 漫画(16), 日本人(16), マジで(16)
日本(64), 増田(60), 安倍(33), マイノリティ(26), じゃなくて(25), 障害者(19), 可能性(19), 平成(16), マジで(16), マジョリティ(16), 自民党(15), 低所得(14), アメリカ(12), なんだろう(12), ブコメ(11), PC(11), 元増田(11), 最低賃金(10), 物理法則(10), YES(10), 機械化(10), 二次創作(10), ワイ(10), はてなー(9), ようじょ(9), 健常者(9), 何度(9), 障碍者(9), 普通に(9), 2018年(9), 下方婚(9), な！(9), IT(9), ツイート(9), 米(9), ネトウヨ(8), いない(8), 共産党(8), DL(8), はてブ(8), トラバ(8), s(8), B(8), Google(8), Twitter(8), 関係者(8), ブクマ(7), アプリ(7), 東京(7), 一緒に(7), 自衛隊(7), 娘(7), 基本的(7), わからん(7), キモい(7), 石破(7), 筋トレ(7), twitter(7), 24時間テレビ(7), ブログ(7), SNS(7), にも(6), なのか(6), 発達障害(6), 1人(6), どんだけ(6), 好きな人(6), サーバルちゃん(6), Suica(6), RDB(6), pixiv(6), 真珠湾(6), 単純作業(6), 回転寿司(6), NHK(6), スマホ(6), RDBMS(6), タトゥー(6), 毎日(6), ？？？(6), 自然法則(6), ツイッター(6), A(6), アベ(5), 一般市民(5), さくらももこ(5), フェミ(5), 1回(5), ちびまる子ちゃん(5), ガチャ(5), ありません(5), ブクマカ(5), 1日(5), Amazon(5), 中国(5), 結果的(5), hatena(5), かな(5), 北朝鮮(5), お客さん(5), 20万(5), ちんこ(5), 障害者雇用(5), いいね(5), 艦これ(5), 2年(5), 被害者(5), 大五郎(5), はてな民(5), 個人的(5), LINE(5), スレ(5), 7%(5), 10人(5), ゴルドー(5), E(5), 民主主義(5), jsfiddle(5), 人間性(5), …。(5), 正義(5), 1割(5), 同人誌(5), 1件(5)
うんち (12), そうだね。うんちだね。💩 (3), パンティー (2), https://jsfiddle.n(2)
■世界三大ペンギン /20180829074002(11), ■[ゲーム]クイズ、検索したら１件しか出ませんでした /20180829140908(10), ■ /20180829165740(8), ■早稲田大学現代文芸コースのセクシャルハラスメント報告書がひどい /20180828223619(7), ■【思考実験】女はゴルドーを避けるのか？ /20180829123815(7), ■なんで漫画の実写映画は /20180829112319(7), ■anond：20180829183228 /20180829184256(6), ■ /20180829113426(5), ■【緩募】コミュニケーション不要な仕事【急募】 /20180829213909(5), ■外人って寿司おいしいって思うのかな /20180828164004(5), ■沸騰した味噌汁 /20180828153328(5), ■ワイシャツってクリーニングに出す物なの？ /20180828221836(5), ■揚げ物 /20180829141503(5), ■anond：20180829154129 /20180829154559(5), ■増田って /20180829004704(5), ■娘ちゃんとうんち /20180829125723(5), ■お見合いするべきか？ /20180829205310(5), ■保護猫さんを飼いたい /20180829081201(5), ■ナンパは軽薄で犯罪的な行為なのか？ /20180829222920(4), ■anond：20180829185836 /20180829190637(4), ■ /20180829121011(4), ■はてな民繊細チンピラ多すぎ問題 /20180829125728(4), ■卵かけご飯 /20180829122540(4), ■ネット上の艦これコミュニティまとめ /20180829031342(4), ■ /20180829111343(4), ■平成が終わる という表現 /20180828120344(4), ■日本人の字幕への意識の低さは何なん？ /20180829155850(4), ■anond：20180829182954 /20180829183228(4), ■筋肉っていつからブームになったの？ /20180828201927(4), ■はてな民のVtuber知識がガバガバ /20180829162352(4), ■anond：20180829161508 /20180829161634(4), ■風邪に幼女って効果あるの？ /20180829094551(4), ■ /20180829140907(4), ■いい歳してコンビニで立ち読みしてるおっさん /20180829083418(4), ■24時間テレビを叩いている方へのお礼 /20180829112304(4), ■フリーアーチャーにならなきゃよかった /20180828115851(4)
5555667(3158)
なる。IoT機器の定点データを保存する、ってことを考えたら確かにRDBじゃきつくもなるわな。
zabbixですら結構ヒーヒー言ってるのに60秒ポーリングで10万ユーザとかじゃ確かに無理だわ。
実サービスではそういうメトリクスってどういう扱いにしてんだろうな。消えてもいい扱い？
いやー、RDBMSの上位互換的な概念ワードは今のところ聞いてないで。
ざっくりNoSQLって括りは「RDBのそれぞれの機能に特化した」ようなものとして、
RDBMSは（速度以外に於いて）それらNoSQLで補っている全機能が入ったパーフェクトな何かって扱いなのは変わっておらんやろ。
言うてNoSQLでアクロバティックなトランザクション処理するよりは大人しくRDB使うやろ。
吾輩は無職である。職はまだ無い。どこで無職になったか、とんと見当けんとうがつかぬ。
何でも薄暗いじめじめした所で手斧を投げられていた事だけは記憶している。
しかもあとで聞くとそれは増田という人間中で一番獰悪な種族であったそうだ。
・・・・
まぁ、前置きの冗談はこの辺までとして、前々から作りたいな思っていた
Webサービスを中々時間が取れず作るのを諦めていたのだけど、
僕自身、プログラミングを生業とする職業では無く、学生時代も特にプログラミングついて何か
始めたのが昨年末の大晦日ちょい前なので、約5ヶ月掛かり、当初想定していた期間より
かなりの時間が掛かってしまい、反省点等含めその辺の事を書けたらなと思います。
■やりたい事（実装した事）
・ゲームユーザー同士を繋げるマッチングサイト（出会い系ではないよ。）
・タグをつける
構成を書いた方が良いと思うので
以下になります。
■構成
--------------------------------------------
FW：Flask 1.0.2
ORM：SQLAlchemy 1.2.7
その他ツール等：Let's Encrypt/fail2ban/等々
--------------------------------------------
ほぼ、既存のベーシックなサーバーサイド側の制御のみです。（jsで非同期通信はしてます）
変えるのもなと思い、取り敢えず上記です。
■選定理由
Railsの名前を良く聞くのでRuby on Rails触ったのですが、
Railsには馴染めなかった（扱えなかった）ので
何かマイクロFWの方が良いのだろうと、Sinatraいこうか思いましたが
Railsの印象が強く残った為、Rubyは止めてPythonに移りました。
今度は初っ端からマイクロFWが良いだろうとFlaskのサンプルを試すと
比較的プログラミング初学者でも扱いやすく覚える事も少ないので、PythonとFlask
の組み合わせで決定。
（気軽にプログラムを書け、自分がイメージしている処理や制御を素直に実現できる点が
書いていて気持ちが良いです。まぁ分からない所も有りますが、そう思わせてくれる点
が良いです。モチベーション的に）
NginxとuWSGIの組み合わせはFlaskで検索すると一番でてくるのでこれに決定。
SQLite3 はマイクロFWだから軽めのDBでたぶん大丈夫だと思ったのでこれに決定
■開発概要
・まずPythonの開発環境を整えようとなり、WindowsにVagrantをインストールして
仮想マシンの環境構築。ゲストOSの中にPyenv等を入れPython環境構築
・上記構築後に取り敢えず小さなサンプルから作ろうとなり、簡単なCRUDをFlaskで行える様にしました。
これができた時は嬉しかったです
・上記が出来てから、本番の開発に移りCRUDをベースにひたすら肉付けていく
→ユーザー登録機能作成/ログイン機能作成/ユーザー情報表示/編集機能/チケット作成/及び編集/バリデーション
・細かいViewの調整とスマホ用のViewも作成（レスポンシブルでは無いので）
・本番用のさくらVPSに環境構築とセキュリティ用のツール導入とLet's Encryptでhttps化
■悩んだ点/反省点
・悩んだのがタグ機能周りになるとどうすればよいか、かなり悩みました。
結論を言うとToxi法を使用しましたのですがここにたどり着き、理解するのに結構時間がとられました。
また、実装したらしたで、今度はそのタグ機能を検索するとなると検索ワードが1つとは限らないので
クエリーを動的に生成する必要が有り、これも実装するのにかなり時間が掛かりました。
SQL文だけならば比較的すぐに検索でヒットしますが、それをSQLAlchemyでどう実現すれば良いか分からず
かなり時間が掛かりました。DB設計やSQLAlchemyの文法に自信は無いですねぇ。。
・1次情報のリファレンスからは情報得ることがほとんど出来ず（たまにはできたが）、
Stack OverflowとQiitaと個人ブログが無ければこのサイトできなかったので
■総評
・5ヶ月と時間が掛かりまた反省点も多々有るが、とりあえずサービス公開まで
もっていけた事が嬉しいです。ただただ嬉しい。
・FlaskとSQLAlchemyの情報が日本語が少ないので公式リファレンスとStack Overflowを
行ったり来たりしたおかげで英語アレルギーがそこまで無くなった。
■成果物
オンラインゲーマー向け（e-sports）のマッチングサイトになります。
名前が安直で小学生が5秒で考えたような名前ですが、安直で気に入っています。
作った理由は、僕はBF1が好きなのでオペレーションキャンペーンと言うモードを
やろうとしたのですが、時間帯が悪いのか過疎なか分からないが全然マッチングしないのですよ。
やりたいのにマッチングしないので出来ないどうしよう、と。
また、昔セールでFarCry3をかなり昔に購入した時（既に4が発売済み）にCO-OPモードが全然マッチしない事が有り
旬が過ぎたオンラインゲームは中々マッチしなくてほぼシングルモードしか出来ない事は割とあると思うんです。
今だとBF4もかなり人数がいない状態なので特定マップのみとか。
なのでオンラインゲームでマルチプレイやCo-opで人を集めたい時、PUBGやFORTNITE等バトロワゲームのスクワッドを
募集する時、オンラインゲームの大会（e-sports）を開きたい時に利用して貰えると嬉しいです。
主に想定ユーザーと考えているのは、FPS/TPS/RTS/MOBA等のPCゲーマーをメインに考えていますがCS機やTCGでも
使って貰えると嬉しいです。
あとViewがレスポンシブでは無く、PC用とスマホ用しかなくタブレット用の中サイズのViewが無いのでご了承下さい。
遊んでも良いよという奇特な方がいましたら当該サイト内でコメント頂けると幸いです
・BF1（PC版）
それでは長々とありがとうございました。
・・・・
日月を切り落し、天地を粉韲して不可思議の無職に入る。吾輩は死ぬ。
ありがたいありがたい。
ScalaとかKotlinとかいろいろ言ってる奴いるが10年後にはどうせJavaが勝ってる。
Javaはnull安全じゃない！とかほざく奴はもちろん@CheckForNullアノテーション使ってから言ってるよな…？
フレームワークは流行り廃りがあるから微妙だが、勉強するならSpringにしておけ。それだけでいい。
Webブラウザに標準搭載のJavaScriptが無くなることもまずありえない。
あとやるならjQueryね。AngularJSとかすぐ廃れるから。
学習コストが高いものって結局広まらないからさ…素直に現実を認めよう。
AnsibleやFabric使ってるやつがいるがどうせ10年後にはブームが去り技術的負債となっている。
シェルスクリプトで代用できるのだからシェルスクリプトでやっておけ。
これだけ広まったRDBが今後使われなくなることはまず考えられない。
実験結果を解析するプログラムをCで書き、解析結果をgnuplotでグラフ化し、グラフを貼り付けたレポートをTeXで作成するのを、全てemacsだけで行うという、今思うと労力だけは修行僧並みの苦行をこなしていた。
結局、このスタイルは修士論文を書き逃げするまで続くことになる(論文の図表は当然のごとくtgif)。
「役に立つけど、死ぬほど使いにくい」とはどういうことかを身を以て経験した感じである。
しかし、この修行もどきが原点になったおかげか、今流行のWeb系の諸々の技術は、さほど難しいと思わなかったり。
また、就職後に経験したオブジェクト指向もシステムプログラミングも難しいっちゃ難しかったが、なんとか投げ出さずに仕事をこなせたのは上述の経験が肥やしになったからかも。
一方で、同じ頃に知ったRDBの、その恐ろしく合理的で分かりやすい思想に感動したり、ここ数年コーディングで小技的に使うMapとReduceをコンピュータ科学の素晴らしい成果だと本気で思えたりしたのも、出発点のハードルがやたら高かった故な気がしている。
しかし、それを踏まえても、あいつらの使いにくさはどうにかならなかったのか。
「役に立つのがそれしかないから泣く泣く使う」なんて、経験しないで済むならそのほうがいいに決まっている。自分が怪我の功名的な肥やしにできたのも結果論でしかないし。
てか今時の学生は、こういう作業に何を使っているんだろう。
