  |
はてなキーワード: リファレンスとは
・STL標準講座
・Effective C++
・Modern Effective C++
・Effective STL
15年かけC++を独学した。
ずっと一人で努力し、風呂、トイレ、布団の中でも勉強し、プログラムを書いた。
基本情報処理、ソフトウェア開発者試験、ネットワークスペシャリストとデータベーススペシャリストを取得した。
しかし、正社員はもとより、時給2000円の派遣プログラマも時給1200円のアルバイトもスキル不足で何十社受けても一社も採用されない。
とはいえ、面接官のレベルは「STLなんて初めて聞いた」「gccて何かの会社？」
「C++の企画書(誤字ではない)を書いてる人なんてのがいるの？」
「じょーほーしょりしけんてのがあるの？外国の話？」
独身で、一切を我慢して娯楽を全く体験しないまま40歳になってしまった。IT業界の人間すべてが恨めしい。
貯金100万もなく、素人が書いたプログラムに対して手順書のとおりにマウスを操作してエクセルにテスト結果を書くだけの仕事ばかりしている。
C++じゃなくてCかC#かJavaか、とにかくC++以外だったらこんな事にならなかっただろうに。
https://twitter.com/crd_tweet/status/1075996340809719808
https://twitter.com/Sakai_Sampo/status/1075996738756866049
ま〜〜〜〜〜〜〜〜〜〜〜〜〜〜た出たよSFファンの「えっ！？ この作品を知らない人がいるなんて！？」マウンティングが。腐臭がする。そういう態度とるくらいなんだからSF老害おじさんにおかれましては日本古典近代戦前文学は言うまでもなく英米仏西伊独南米東欧文学の名作は当然読んでるしアニメ漫画ゲームの有名処は全部触れてるんですよね？ どんな人でも絶対に「あの有名どころを読んでいない」なんてこと当然あるに決まってるだろ。SFの業界人がSFの有名どころを読んでなかったらそうも言われても仕方ないかもしれないが、共同リファレンスみたいな一般市民が普通の司書さんに質問した程度の案件でなんだその態度は。大体そもそも多読が可能かどうかって個人個人の特性によることが大きいから名作を全部おさえるみたいなのってできるひととできないにとが明確に分かれるだろ。SF語るのに1000冊読んでいる必要はないって口では言いながらこういう事例ですぐマウンティングしてくるからSF老害は信用ならねえんだよ死ね。
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次元立体構造再構処理した結果と、レーザライダー、光学カメラ、高精度カメラで画像処理した結果を比較評価をすることで、提案手法の有効性を詳細に評価できるようになった。
お前そのカメラ買って即売っぱらっとるやんけ。ようするにこいつ研究成果においても嘘ついてるんですよ。どうにもならん、クソオブクソ。予算不足とかどうとかそういう話以前。小保方みたいなもんですよこんなん。
公式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のはてな同窓会老人村界隈でゴチャゴチャ言い合ってるのも結構なことだが、所詮は老害化しつつある村であることをそろそろみんな自覚してはどうか。
実際に教える側としてそういうケースに遭遇した。
自分は人には割としっかり教えるようにしてる。
それまでは「面倒くさい奴、変な奴、あからさまにバランスの悪い奴」を教えてきたので「何とかなるだろう」と少し考えていた。
相手の人の尊厳の問題もあるので、具体的な話はぼかして書くけど、当方は技術職。
採用としては「アシスタント業務のようなもので、高度に独創性が必要な部門ではないので、基礎的な技術がこなせればOK。真面目な人格が重要」という判断だったらしい。
ネットで検索すれば、「初歩の初歩」としてリファレンスが山ほどでてくるような技術。
その道が好きなら、高校生でも知っているようなやり方を知らない。
「これ、仕事の時間内に教えなきゃダメなレベルの技術かな」と思いつつ教えたが、１つ技術を覚えるのに、早い人なら２日、普通なら１週間で出来るものが、その人は１ヶ月かけても出来ない。
周りの仲間も代わる代わる教えたが、みんなサジを投げるレベルの物覚えの悪さ。
パワハラ的な教え方はしていない、むしろ、子供に教えてるんじゃないかというレベルの丁寧さでも。
どうしようもなくなって、本当になにも技術が必要ない単調な作業をなんとか探してきて、仕事としてはそれだけやってもらう合間に、練習をしてもらっていた。
評価はかなり困ったが、「仕事にあたる態度は真面目（あからさまなやる気のなさや態度の悪さを見せない）」という点を本人に伝えて、
「しかし技術の上積みはどうしても必要なので、その態度で焦らず頑張って欲しい」と伝えた。
でもその人は辞めた。
自分がこの職場で活躍できる場所がないことが分かってしまったようだった。
活躍の場がない所にいつまでもダラダラいさせても、その人の時間も無駄にする。
HTML/CSSはリファレンスなしで書けるし、WAI-ARIAを用いたアクセシブルなコーディングもできる。
CSS設計を意識して保守性を大切にしたコードを書いているし、CSSアニメーションでインタラクションも操作できる。
SVGを一から書く方法やいくつものブレイクポイントを持ったページのコーディングスキルも身につけた。
Gitでバージョン管理をしたり、モジュールバンドラーやタスクランナーでscssのコンパイルやリントを通したりする能力も得た。
インプットが大好きで、毎日毎日様々なWebに関する知識を頭に詰め込んだ。
だけどJavaScriptは書けない。
JQueryをコピペして簡単なDOM操作を行うのが限界だった。
然しながら、昨今のフロントエンドエンジニアはJavaScriptが書けて当たり前だし、
各種JSフレームワークやWeb Assembly、Web Componentsを使いこなして開発している。
SSG, SSRが主流のこの時代、生のHTMLを書いているような人種は淘汰され、
バーティカルリズムや余白設計、配色理論を意識した整ったレイアウトをXDやIllustratorで作れるようになった。
でも「整った・整然としたレイアウト」は作れても、その先に進むことはできなかった。
だけど、藻掻き続けても道が拓けない。
もうこの先、どのように歩み進めればいいのかもわからない。
助けて欲しい。
何者にもなれない自分は嫌だ。
