  |
はてなキーワード: リファレンスとは
https://twitter.com/crd_tweet/status/1075996340809719808
https://twitter.com/Sakai_Sampo/status/1075996738756866049
ま〜〜〜〜〜〜〜〜〜〜〜〜〜〜た出たよSFファンの「えっ！？ この作品を知らない人がいるなんて！？」マウンティングが。腐臭がする。そういう態度とるくらいなんだからSF老害おじさんにおかれましては日本古典近代戦前文学は言うまでもなく英米仏西伊独南米東欧文学の名作は当然読んでるしアニメ漫画ゲームの有名処は全部触れてるんですよね？ どんな人でも絶対に「あの有名どころを読んでいない」なんてこと当然あるに決まってるだろ。SFの業界人がSFの有名どころを読んでなかったらそうも言われても仕方ないかもしれないが、共同リファレンスみたいな一般市民が普通の司書さんに質問した程度の案件でなんだその態度は。大体そもそも多読が可能かどうかって個人個人の特性によることが大きいから名作を全部おさえるみたいなのってできるひととできないにとが明確に分かれるだろ。SF語るのに1000冊読んでいる必要はないって口では言いながらこういう事例ですぐマウンティングしてくるからSF老害は信用ならねえんだよ死ね。
前回は、Webアプリの骨組み（スケルトン）に、SQLでデータの追加と取得をやりました。
前回作ったメッセージ一覧に、[編集]のリンクも入れておいた。
<td><a href="welcome/update/<?php echo $item['id']; ?>">編集</a></td>
という１行の部分。
ブラウザーでHTMLソースを見ると、以下のようなHTMLになってるはず。
これは「メッセージID番号が2」を対象にして、編集ページにジャンプすることを意味する。
「http://localhost/waf/welcome/update/2」というURLで編集ページにアクセスしたら、メッセージID番号の「2」を受け取れるようにしたい。
// 更新画面
public function update($id = '')
{
$this->load->view('chat_update');
}
CodeIgniterでは、URLから文字列を取り出す方法がいくつか用意されている。
// 更新画面
public function update()
{
$this->load->view('chat_update');
}
CodeIgniterで、URLの文字列から、特定部分の文字列を取り出す方法を見ておこう。
例えば、「http://localhost/waf/welcome/update/aaa/bbb/ccc」というURLにアクセスしたとき、CodeIgniterではURL中の「aaa」「bbb」「ccc」という部分は、以下のようにして取り出せる。
$seg1 = $this->uri->segment(1); // → 1番目のURL文字列：「welcome」＝コントローラーのクラス名
$seg2 = $this->uri->segment(2); // → 2番目のURL文字列：「update」＝クラスの中のメソッド名
$seg3 = $this->uri->segment(3); // → 3番目のURL文字列：「aaa」の部分
$seg4 = $this->uri->segment(4); // → 4番目のURL文字列：「bbb」の部分
$seg5 = $this->uri->segment(5); // → 5番目のURL文字列：「ccc」の部分
：
URLを「/」で区切って、base_url（http://localhost/waf/）の次から順番に、1番目のURL文字列、2番目のURL文字列、3番目のURL文字列、…とsegment()メソッドで順番を指定すれば取得できる。
データベースでメッセージIDを指定して、メッセージを取り出す機能を用意しよう。
public function read_message_by_id($id = 0)
{
$sql = "SELECT * FROM talk WHERE id = ?";
$param = array($id);
$query = $this->db->query($sql, $param);
return $query->row_array();
}
「WHERE id = 2」とすれば、メッセージID番号が2のメッセージのデータが「talk」テーブルから取り出せる。
もし該当するデータがなければ、返されるデータは空になる。（データが返ってこない。）
CodeIgniterの「row_array()」は、１件分のデータを配列の形にして返すメソッドだ。
<?php defined('BASEPATH') or exit('No direct script access allowed');?>
<!DOCTYPE html>
<html>
<head>
<base href="<?php echo base_url(); ?>">
</head>
<body>
<p>メッセージを変更して「更新する」ボタンを押してください。</p>
<form action="welcome/update" method="post" accept-charset="utf-8">
<label>メッセージ</label>
<input type="text" name="message" value="<?php echo $talk['message']; ?>">
<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">
<input type="hidden" name="action" value="update">
<?php else: ?>
<p>※該当するメッセージがありません。</p>
<?php endif;?>
<button>更新する</button>
</form>
<p><a href="welcome/index">戻る</a></p>
</body>
</html>
データベースから取り出した１件分のメッセージを表示する部分を追加した。
<input type="text" name="message" value="<?php echo $talk['message']; ?>">
の「<?php echo $talk['message']; ?>」という部分だ。
これで変更したいメッセージの本文を表示できる。
あと、編集したメッセージをWebサーバーに送信できるように、Formタグや送信ボタン（「更新する」の部分）も追加した。
<input type="hidden" name="id" value="<?php echo $talk['id']; ?>">
という１行も仕込んである。
// 更新画面
public function update($id = '')
{
$id = $id ? $id : $this->input->post('id'); // id -> segment or post
$action = $this->input->post('action');
if ($action == 'update') {
$message = $this->input->post('message');
$this->chat_model->update_message($id, $message);
}
$data['talk'] = $this->chat_model->read_message_by_id($id);
$this->load->view('chat_update', $data);
}
メッセージID番号を指定して、データベースから取り出し、Viewに渡すデータを用意している。
ユーザーがメッセージの編集をしてWebサーバーに送信したら、データを更新する指示を出す部分も追加した。
$action = $this->input->post('action');
if ($action == 'update') {
$message = $this->input->post('message');
$this->chat_model->update_message($id, $message);
}
モデルにupdate_message()メソッドを用意して、$idと$messageを渡せば、該当データを更新するようにしたい。
次は、モデルでupdate_message()メソッドを用意しよう。
// Update
public function update_message($id = 0, $message = '')
{
$sql = "UPDATE talk SET message = ? WHERE id = ?";
$param = array($message, $id);
$this->db->query($sql, $param);
return $this->db->affected_rows();
}
SQLの「UPDATE」を使えば、指定したレコード（１件分のデータ）を更新できる。
「UPDATE talk SET message = ? WHERE id = ?」で、talkテーブルのmessageをidを指定して更新している。
CodeIgniterの「affected_rows()」メソッドは、更新した行数を返す。＝成功なら1行、失敗なら0行となる。
コントローラーの「$id = $id ? $id : $this->input->post('id');」という行は、$idの受け取り方が2パターンあるので、それに対応している。
＝編集ページの表示で、1回目の表示と、2回目以降の表示で、$idの受け渡し方が変わっている。
URLに埋め込む方法（上記の1回目のような方法）は、ユーザーが勝手に値をいじれるので、基本的には使わない方が良い。
以上で、SQLの「UPDATE」を使った、データの更新ができた。
長々と説明したが、今回の大事な点は、SQLの「UPDATE」の使い方だ。
CodeIgniterの使い方や、Webサイトの作り方（FormタグなどのHTMLの知識）は、オマケ程度に見ておいて欲しい。
次回は、データを削除するSQL「DELETE」の使い方を見てみよう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成
anond:20181101225335 増田式プログラマー養成講座 その15 Webアプリの完成見本
anond:20181101230220 増田式プログラマー養成講座 その16 Webアプリの完成見本（続き）
anond:20181104161900 増田式プログラマー養成講座 その17 Webアプリの骨組み
anond:20181104233013 増田式プログラマー養成講座 その18 SQLでデータの追加と取得
anond:20181110120715 増田式プログラマー養成講座 その19 SQLでデータの更新 ←★今ここ★
anond:20181110182445 増田式プログラマー養成講座 その20 SQLでデータの削除
：
前回はオブジェクト指向プログラミング（OOP）の使いどころを学ぶために、MVCフレームワークを使ってみました。（ほんの触りだけ）
OOPに関する有名な本はたくさんあります。Amazonでレビューの評価が高い本は、定番の本が多いです。
だけど分厚い本は、ある程度プログラミングに慣れてから読んでみないと、最初は意味がチンプンカンプンだと思います。
（最初は意味が分からなくても）なるべく早い時期に1回は読んでみた方が良いと思う本をピックアップしてみます。
この本は、OOPの概要、基礎知識がコンパクトにまとめられています。
この本を１つの目安にして、今後の学習指針を立ててみて下さい。
https://www.shuwasystem.co.jp/products/7980html/4614.html
この本は、OOPも含むプログラム設計のノウハウや原則をまとめて紹介しています。
カタログ的に、各テーマを広く浅く紹介してるだけなので、詳しい内容は個別に掘り下げる必要がありますが、それでも概要を知る上では役立ちます。
今すぐ理解できなくても、「あー、そういえば、そういう話もあったな」と後で思い出せる程度に眺めておくだけでも十分だと思います。
（第3章にある「UNIX哲学」は、初心者にとってプログラミングの良い指針になると思います。）
https://gihyo.jp/book/2016/978-4-7741-8361-9
この本は、上記2冊の内容を具体的な事例で説明しているような本です。
これらの内容はそれぞれが1冊の本になるほどボリュームの多い内容ですが、本書ではそれらのエッセンスをうまくまとめていると思います。
サンプルコードはRubyで説明されていますが、何らかのOOP言語を使ったことがあれば、Rubyの文法を知らなくても、だいたい意味は分かると思います。
プログラミングの入門書を数冊読んだ程度の段階では、上記の本を読んでもいまいちピンと来なくて、意味が理解できないと思われます。
しかし、将来自分がぶち当たるであろう壁、課題を先取りしているつもりになって、「こんなことも考慮してるんだな！」と雰囲気だけでもつかんでもらえればいいんじゃないかと思います。
PHPを使って、OOPの基本的な仕組みを説明をしたので、PHPの入門書を挙げるなら、とりあえずこの１冊。
自分にとっては分かりやすい説明だと思うのですが、類書はたくさんあるので、実際に本屋で確かめてみましょう。
Javaの入門書で文法の基礎を学んだら、次に読んでみたい本。
「デザインパターン」という知識があると、他人が書いたプログラムを読むときに役立つと思います。
（なんでこういう書き方をしてるんだろ？とか、定番の書き方＝パターンがいくつかあるので。）
グチャグチャな汚いコードを綺麗にスッキリさせるノウハウがあります。
リファクタリングに関する知識を学ぶと、プログラムの書き方が改善されて、後で自分がメンテナンスするときに苦労が減ります。
今の段階では、パッと思いついた本はこんなかんじだけど、他にも良い本はいっぱいあります。
自分が分かりやすいと思う説明方法と、他人が分かりやすいと思う説明方法は、必ずしも一致してない場合が多々あります。
図書館や本屋で、実際に本の内容を確かめてみて、自分にとって一番分かりやすいと思える説明の本を探してみてください。
リファレンス（文法の辞書など）は、読む頻度が多ければ、買って損はしない＝元は取れると思うので、自分への投資だと思って、必要な本は買うようにしましょう。
（プログラミングの専門学校とかに行ったら、学費が何十万円もしますね？それを思えば本なら安いものです。）
プログラミングに限らず、他の勉強でも同じだと思いますが、最初は知らないことの連続ですね？
プログラムのサンプルコードを見ても、意味が分からなくて、中身が不明な「ブラックボックス」に見えると思います。
でも、いったん意味が分かるようになると、霧が晴れたように、急激に視界が開けてきます！
学習曲線で言えば、滑らかな右肩上がり（／）ではなく、ある時グイッと変わる階段状（＿l￣）の変化に近いと思います。
なので、最初は分からないことが多く感じても、それが当たり前なので、あまり気にする必要はないです。
理解を早める補助として、上記のような参考書も活用されてみて下さい。
今回までで、手続型言語（構造化プログラミング、オブジェクト指向プログラミング）の基本を知りました。
次回は、問合型言語（SQL）を学び、データベースを使いましょう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書 ←★今ここ★
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
：
iPhone XSとPixel 3が発表されて、どっちも高いなぁ、ヤベェなぁと僕は思うんだけど、「スマホが高くなったのではない、日本が貧しくなったのだ」という意見をよく見かける。
2011年の段階で、iPhone 4Sの64GBモデルが67,200円。一番安い16GBモデルが46,080円。
64GBモデルで比較するとiPhone XSが121,824円(税込)だから、7年で1.8倍高くなっている。
外国では、7年前に6万7千円を支払ったのと同じ金銭感覚で12万円を出せるってこと？
っていう結論を書くために、過去のiPhone、Googleのスマートフォンの価格を調べてみた。
過去どれだけ安いかが知りたかっただけなので、全部は調べていない。
64GB 121,824円
256GB 140,184円
512GB 165,024円
64GB 134,784円
256GB 153,144円
512GB 177,984円
16GB 46,080円
32GB 57,600円
64GB 67,200円
16GB 70,200円～72,576円 (docomo 72,576円 au 70,200円 SoftBank 70,080円)
32GB 79,920円～82,944円 (docomo 82,944円 au 79,920円 SoftBank 80,400円)
64GB 90,720円～93,312円 (docomo 93,312円 au 90,720円 SoftBank 90,720円)
2011年 67,200円
2011年にはiPhoneは安くて46,080円で手に入っていたので、最低スペックしか買わない貧乏人にとっては3倍近い価格になっており、超高く感じられる。
64GB 95,000円
128GB 107,000円
64GB 119,000円
128GB 131,000円
16GB 39,800円
32GB 44,800円
32GB 59,300円
64GB 63,400円
32GB 74,800円
64GB 80,800円
Googleのスマートフォンも、まず2013年～2015年で、32GBで比較して、
と高くなっており、2015年～2018年も、64GBでの比較で、
と価格が約1.5倍になっている。
Nexus 5は軽い気持ちで買ったけど、もはや遊び半分で買うには高すぎる。
リファレンス機は遊びじゃない。
http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session
と厳しい叱責を受けたため、無能の見識を書いてみた。
「聞くは一時の恥、聞かぬは一生の恥」のとおり、
せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存
作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)
確認している間に1時間はかかるからいいやと思ってしまっていた
師はきっとJWT生成直後3秒でユーザーが
と気づいて通報
そして師が2秒で
「これは、セッションハイジャックだ！」
と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している
これは確かにJWTだと厳しそうだ
セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか
(師はログインを即座に検知してセッションを切れるから問題ないのか)
とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている
この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える
これはまずい、自分の今までの見識の甘さを思い知らされた
keyは初回に設定したのみで、定期的な交換を勧める文が見つからない
私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか
JWTはhash化してつないでいる前提で
解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った
https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83
英数字大文字小文字で約60の時は10桁で20万年と書いているが
現代の解析技術は20万倍は速度が出ると仮定して1年として計算する
日本語に直すと60京4661兆7600億年かかる計算となった
実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ
そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか
私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる
まず、IDとpassを内蔵するネイティブアプリに対するapiサーバでの実装経験しかないこと
JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく
そのためapiサーバで上記前提で用いた場合に考えたことを書く
webアプリのJWT実装経験はないので、そちらの論は差し控えさせていただく
では危険で
JWT送信→セッション(cookie形式?)送信切り替え→セッションからuser_id取得
とりあえず思いついたのは下記だった
tokenはheaderにbearerで付けユーザーID(あるいはそれに代わる特定可能な識別子)が含まれる
httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた
(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)
0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない
というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので
JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった
※余談だが、たまに送る回数が少ない方が安全という
攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた
(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)
その前提のため、わざわざ
JWT送信→セッション(cookie形式?)送信→セッションからuser_id取得
で接続しても、おそらくcookie形式で送れる何かもJWTらと同じ方法で抜かれると思われる
つまりcookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった
つまりcookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら
JWT→user_id
でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った
ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが
セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが
それを指していたのであろうか
余談だが、ブコメの雰囲気に日和って「ユーザーIDのみ入れ」(そもそもJWTを自然に作れば入るのだが)
というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが
結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので
正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている
強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか
でも暗号化したらよいのでは、と思った
expを適切に設定しつつ、必要ならアカウントロック機能を入れる
(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)
少なくともapiサーバ→ネイティブアプリに関して、セッションIDを含めても危険性は変わらない
正直webアプリでも大して変わらんのでは、と思っているのは内緒である
土日祝日なしのシフト制だが22時帰宅の毎日で技術に対する興味が薄れて労働マシーン化していた。
そんな時に Leaflet という面白そうなモノを見つけたWeb地図のためのJavaScriptライブラリらしい。
学生の頃にちょこちょこ記録していた美味しいお店リストや忙しくなる前に遊んでたMMOのデータを元にそのライブラリを使ってwebコテンツを作りたくなった。
15年ぶりに「とほほのJavaScriptリファレンス」を見た、今はさっと読んでいる段階だ、IT業界のSIerの下請けの事務処理や保守や問い合わせの対応マシーン化していた
自分にはプログラミング言語を触れたのは15年ぶりだった・・・まったくわからないが読んでいて楽しい。
この感覚は学生の頃によくあったが社会に出たらいつの間にか忘れて早く帰ることしか頭になかった。
有給や休日での代休は取ると元請けから睨まれ最悪、自分を含めた現場の技術者を外すして別の技術者に入れ替えるよう命じられるため休むことができなかったが久しぶりに取った土日の連休に
Leaflet と言うものを見てwebコテンツを作りたいなーと思ったときに頭の中で誰かが「もっと休もう、休んで自分のやりたいことを伸ばす時間を作ろう」という言葉を自分に掛けた。
休まないのは経営者ぐらいでいい労働者はもっと休むべきだ、今日で休日は終わり明日から忙しい日がまた始まる。
Leaflet と言うJavaScriptライブラリを使って作りたいものが出来たのだから、きっとこれは何かのチャンスに違いない。
たとえばC#など.NET系のリファレンスはMSDNで読むことができる。
RubyだってHaskellだってScalaだって、公式サイトにガイドぐらい置いてある。
Oracle、DB2、MySQL、PostgreSQL、SQLite、AccessなどSQLが実装されたDBMSは様々にあるが、どれを取っても仕様が違う。
皆が標準SQLに従っていてその上で適当に増設している程度ならよいが、もはや誰も標準SQLに従う気が無い。
根幹的に必要な機能があったりなかったりするから、あるDBMSで書けるようになったからと言ってSQLを覚えたとは言えない。
これと上記１とのせいで、何かググった時に特定のDBMSでしか解決法にならないものが大量に出てくる。
最近のプログラミング言語は大抵、雑に書いたってコンパイラが適当に最適化してくれる。
同じ結果を生むような二つのコードは、よほど下手くそに書かない限りは同じような実行速度になる。
SQLもオプティマイザが最適化はするが、ほぼ同じような二つのコードで速度が全く変わったりする。
そのため実行計画というオプティマイザの中間言語のようなものを読んであげて、
より速い中間言語が生成されるようSQLをチューニングし直さなければならない。
これでは何をやっているのかわからない。
有名なサイトでは、初心者が必死で書いたような可愛らしいSQLを「それでは遅すぎるんじゃ」とけちょんけちょんにけなし、
なんかシンプルなのだけれどよくわからない文法を一杯使って実行速度を高めたのを「正解」としていたりする。
しかもその文法、ググってもろくな解説が無かったり、特定のDBMSに依存してたりと使えないオチ。
上手い人はSQLを綺麗に書く。だけど、その綺麗さの基準が人によって違う。
エディタが単なるメモ帳でしかないようなDBMSも多いから、インデントの文字数さえ個々人に任される。
インデントは2文字か4文字か。SELECTで改行するかしないか。カンマは列の後ろか、前か。
いろいろなサイトに色々なことが書いてあったけれど、全部違うこと言ってた。
つまり各々綺麗に書ければいいやということであり、読むほうも宗教が違ってもまあ綺麗なら読めるから困りはしない。
何かの解決法をググるたびに違うスタイルだからどう書いていいのかわからない。
結局なんかいろいろな上手い人のスタイルをツギハギした新たなスタイルが世に誕生してしまうのだ。
吾輩は無職である。職はまだ無い。どこで無職になったか、とんと見当けんとうがつかぬ。
何でも薄暗いじめじめした所で手斧を投げられていた事だけは記憶している。
しかもあとで聞くとそれは増田という人間中で一番獰悪な種族であったそうだ。
・・・・
まぁ、前置きの冗談はこの辺までとして、前々から作りたいな思っていた
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版）
それでは長々とありがとうございました。
・・・・
日月を切り落し、天地を粉韲して不可思議の無職に入る。吾輩は死ぬ。
ありがたいありがたい。
http://www.yomiuri.co.jp/national/20180413-OYT1T50003.html
この件ね。
http://b.hatena.ne.jp/entry/www.yomiuri.co.jp/national/20180413-OYT1T50003.html
yujilabo 年度末になると補助金の満額まで使い切らないと翌年度の補助金が減額されたりもするため、ただちに必要でない機器や薬剤を購入して保管していたりすることはよくあると思う。無駄なので仕組みのテコ入れが望まれる
timetrain 予算が無いのが最大の原因だろうな・・
例によってはてなブックマークの論調はこんなんなんだけど、 https://kaken.nii.ac.jp/ja/grant/KAKENHI-PROJECT-15H05528/ こちらから科研費の交付状況を見て頂きたい。年 500 万という予算が妥当かどうかは置くとして
リファレンスシステムとしてレーザライダーに加えて、光学カメラと高精度カメラを導入した。レーダで2次元立体構造再構処理した結果と、レーザライダー、光学カメラ、高精度カメラで画像処理した結果を比較評価をすることで、提案手法の有効性を詳細に評価できるようになった。
お前そのカメラ買って即売っぱらっとるやんけ。ようするにこいつ研究成果においても嘘ついてるんですよ。どうにもならん、クソオブクソ。予算不足とかどうとかそういう話以前。小保方みたいなもんですよこんなん。
レベル5 : マスターレベル。拡張ライブラリを記述できるだけでなく、言語の内部仕様、処理系の実装等についても明るい。
レベル4 : 問題なく日常的に利用できるレベル。言語を使うだけでなく、その言語のライブラリを作ったり、フレームワークを作ることもできる。
問題なく日常的に利用できるけどリファレンス禁止は無理な私はレベル２なの？
というかどんなコードを書く前提なの？
競技プログラミング解くならリファレンスは要らんけどGUI絡んだりWEBとかだと絶対無理だけど？
スレッドとか普段使わないからどの言語でも調べないと無理ですけど？
コピペされすぎだろ
公式HPではそこで書いたことが全て公式の発言になってしまうことから、
「こうやって作るべき」といった公式の中でも意見が分かれる議論には言及できず、
どうしても事実だけを淡々とまとめるリファレンスのような内容に偏ったりと、
（どちらかというと公式より同じ利用側の立場から教えてもらえる書籍の方が入りやすい）
それ以外のネットの誰が書いてるかわからない無料の情報は間違ってる場合も多い。
ネットの仕組み上、正確な情報より、読み手が面白いと思ったものが
Stack Overflow レベルになると間違いは少ないとは思うけど、
日本の Qiita とかで話題になってる技術記事はひどい内容のをよく見かけるね。
（反論してる人が少ないのは読み手が間違いに気づいてないのか、批判は失礼だと思ってるのか）
一方、書籍はその分野である程度評価されている人しか出版の話にならないので
最低限の内容の正確性は保証されていたり、
そもそも金を取るので読みやすさとかに配慮されていることが多い。
また書籍一冊分の分量からしても技術の全体像が体系化されて説明されるので
まぁ、最新情報が手に入りにくかったり、読者の最大公約数を取るので
高度やマニアックな内容に触れにくかったりという側面はあるね。
要は、それぞれ一長一短あるんだから、賢く使い分けるのがよいと思う。
俺からしたら、両方のいいとこ取りをすればいいのに、
最近Twitterの創作界隈で #魔女集会で会いましょう というタグが流行している。やたら流れてくるのでTL上で一度や二度はタグを見たことがある方もいるだろう。
これら#魔女集会で会いましょう タグの付いた作品は、Twitter上で1作品概ね1〜４枚の画像としてアップロードされている。大まかなストーリーは、どの絵師が描いたかに関わらず「魔女が人間の男の子を拾い、育てる。時は流れ、育った男の子は魔女のナイト的な役割を担う」という感じである。
もちろん異なる絵師が各々作品を作っているのだから多少の違いはあるが、大体そんなところである。
これらの作品に対して、わかり手（@anbakurakoya）氏が非常に痛快な批判をしていたのでまずは紹介したい。毒親に育てられた身としては、「ああ、わかり手さんは毒親（母親側）問題について理解があるんだな」ということがよく伝わってくる。しかし、わかり手氏の批判はツイッター界隈の老害化の象徴であるかのようにも見える（これについては後述）
まずはわかり手氏の良さを伝えることからはじめよう
魔女集会タグからダダ漏れてる「彼氏みたいな息子が欲しい♡」という欲望、それリアルでやると毒親まっしぐらコースなんでマジで気をつけてな…。
「彼氏みたいな息子が欲しい」という願望を持つ母親（毒親の一種）が一部にいて、とんでもないことになっているのは経験上よく分かる。また、毒親が自分のキモさについて自覚的でないというのも共感できる。
さらに、下記のように「リアルと創作を区別しろ」と仰っているのも非常に納得が行く。
自己擁護の事例としてはこういうのね。いやその関係性が「幸せ」じゃねぇだろ、リアルでやったら毒親まっしぐらだろって話をしてるんだけど、どうも「虚構と現実の区別」とか言いつつ全く区別がついてないっぽくて怖いんだよね。
リアルと創作というのは別のものであり、明確に区別を付けるべきだという意見は全くその通りだと思う。
で、ここで立ち止まって考えてみよう、 #魔女集会で会いましょう タグとはそもそも一体なんなのか？？#魔女集会で会いましょう タグを叩いたり援護したりしている人は当然趣旨をある程度は理解していると推測されるが、念の為確認してみよう。
このタグは九頭さん@coneshait という方が最初に始めたタグで、元ツイは以下のようである。
https://matome.naver.jp/odai/2151839444121733201
#魔女集会で会いましょう このタグで、『魔女が拾った男の子が成長して、魔女よりでかくなって(ごつくてむさくてがっしりしてて)魔女を全力で愛して守る男になる話』の絵を描きますので、誰か描きたい方いらっしゃればこのタグつけて好き勝手に…
ここに絵師が集まって、沢山の作品が投稿された模様である。2日後や3日後の「どんな設定盛っても構わん」という追加の発言もあるものの、多くの創作が1レス目のお題に沿った『魔女が拾った男の子が成長して、魔女よりでかくなって(ごつくてむさくてがっしりしてて)魔女を全力で愛して守る男になる話』というリファレンスに沿った内容となっているようである。
なぜこういったタグが流行るのかと考えると、絵師が「お題」に餓えているか、流行に乗っておいて自分の絵を少しでも見てほしいと思うからなのではないか。
絵を描く力と、ストーリーを考える力というのは全く別物である。一枚絵の画力はあるがストーリーはあんまり思いつかないというような絵師がこういったタグに飛びつくのも合理的だと思う。魔女と青年を絵にしたら映えそうだし。
ではここでわかり手氏の発言の話に戻ると、 #魔女集会で会いましょう タグに群がっている人に「毒親願望」があるのだろうか？これはTwitter上の流れを見た私の推測だが、タグに群がる人々の多くは毒親願望を持っておらず、「魔女とかショタとかのかっこいい絵を描いたり見たりしたかった」という程度の意思しかなかったのだと思う。
ここでもう一度わかり手（@anbakurakoya）氏のツイートを引用する。
魔女集会タグからダダ漏れてる「彼氏みたいな息子が欲しい♡」という欲望、それリアルでやると毒親まっしぐらコースなんでマジで気をつけてな…。
果たして、「魔女集会タグからダダ漏れてる「彼氏みたいな息子が欲しい♡」という欲望」なんてあったんだろうか？お題なんて記号にすぎず、毒親願望なんて多くの人が持ちあわせていなかったところにわかり手氏が「彼氏みたいな息子が欲しい♡という欲望」なるありもしない概念をいきなり持ち込んでしまったのではないかと私は考察する。
同時に、わかり手氏のこのツイートについても的外れであると思う
私がこのツイートを的外れであると思う理由は「ストーリーを考える手間を極力省き、決まったお題で絵を描く遊び」をしているところに「ストーリー考えろ！」と言うのは、ナンセンスだからである。
毒親についてであっても、そうでないことであっても、自分の意見を貫き通せるのは素晴らしいことである。また、経験則から色々なことを語るのは、後の世代にとって有益となる可能性が大いにある。
だがしかし考えてほしい。刑事モノのドラマを見て雑な気持ちで楽しんでいるときに「本物の刑事はこんなんではなくてだな...これは、現実に全く則していなくて...」とやたら絡んでくるオッサンがいたら「老害キモっ」と思わないだろうか？
わかり手氏はまさにその老害の絡み方をしていないだろうか？
Twitterの特性上、TLに流れてくるのは基本的にはフォローしている人達の意見である。しかしフォローしている人の意見なんて小さな部分集合に過ぎない。フォロー外にはフォロー外の世界があり、当然自分より若い人達だっているし、そこにはそこの掟がある。
Twitterのはてな同窓会老人村界隈でゴチャゴチャ言い合ってるのも結構なことだが、所詮は老害化しつつある村であることをそろそろみんな自覚してはどうか。
