  |
なんで帰らないの。
それとも同調圧力に弱いの？
コミュ障だから「か、か、かえらせてくだしゃい」になっちゃうの？
面倒だったら仕事やめればいいじゃん。
誰もとめないし。
昔有名になった人や物の再来のことを「平成の○○だ」とか言ってたよね。
でも流石に30年ちかく経つともう言えなくなってきた。
言ってる人もいないもんね。
こういう年号が変わるたびに復活しては消えていく言葉も死語になるのかな？
まあそれは良いとして、
こんなことを社会生活でいうと不適合者のレッテルを貼られてしまうのでここにこぼす。
子育てよりもそれに付随する大人同士の付き合いの方が何十倍もつらい。
そんなのはご近所付き合いに比べれば本当に全然なんでもないことに思える。
毎朝笑顏で「大変よねー」と挨拶をかわす
行事があると一緒に出てバザーなんかをする
そんなことのいちいちが本当に本当につらい。
でもそうすると子供も自分と同じ社会的不適合者になるかもしれないのでできない。
旦那はもっと楽に距離おいてつきあえというが、それができたら苦労しない。
俺は…家に帰りたいんだ。一人で過ごしたいんだ。
誰かの話す声を、誰かの姿を見たくないんだ。
ずっとリモートワークでもいいんだ。
でも、日本の企業はリモートワーク嫌い。オープンオフィス大好き。
少ない精神力を通常以上に削られていく
開発の人は能力が高いほどやる気がないということ。
こちら側がどれだけその仕様がユーザにとって使いにくいか説明しても、
理解してくれない。
修正しようと思えばできるんだろう。
ということで、能力の高い人ほどやる気がない。
そういう人たちがやることといったら、真新しいオフィスの、
だだっ広い会議室で大騒ぎすることだけ。
シン・ゴジラ観てきた。
勤め先が武蔵小杉のNECビルだったのと元カノの家が多摩川向かいの沼部駅近くだったので、
多摩川絶対防衛線あたりは土地勘相まってテンションがやばかった。
返す返すも尻尾で引っ掛けて倒してくれないカナーって思いが通じなくて残念無念。
即座に、マルノウチスゴイタカイタワーに除念してもらったけど。
多摩川に防衛ラインを設ける下りで次に思い出したのがマヴラヴオルタナティブ。
全てを無効化して豊体で迫りくる恐怖に絶望するのと、どちらも選べない。
精神的に打ちのめされながら目を離せない。久々に思い出した感情だった。
35Fあたりで、ちょうどゴジラと目が合う高さになるのだろうか。
あれだ、ジュラシック・パークのあのシーンだ…幼心だったり、
青い頃の定番の古傷ばかり思い出す。…考えたくない。寝よう。
こうは考えられないか？
デビューしたての女装子ちゃんたちが勇気を出してレストランに入り
「あの、レディースセット、一つ」
と恥じらい気味に言ってそれをイケメン店員さんが普通に持ってきてくれるときの喜びのために
そのセットはあるのだと。
手順も○○が●●になったら◆◆するって条件付けがぜんぶ明確なのでおすすめ
まあそれでも俺みたいな料理下手は失敗するんだけど
これ本当に自分も腹立つんだけど、たいていの料理本のレシピって、いわゆる「設計図」じゃなくて、ただの「ガイドライン」みたいなもんだと思う
つまり、作り方についてすでにある程度の知識がある人に向けての説明
「適量」が分かる人「少々」が分かる人「下ごしらえをしたエビ」がどういう状態か分かる人
向けの、大まかな指針
http://gigazine.net/news/20160802-pokeiv-pokemon-go/
GIGAZINE経由で話題になっているサイトの仕組みについて、私はあのサイトの作者でないけど、解説してみます。
A. パスワードが盗られのではなかろうか
の3点と思われます。
実際に中の人がどういう運用しているかは中の人次第なので、信じるか信じないかという話になるから、水掛け論がはじまるだけなのでやめときます。
まずAについて
Pokémon Trainer ClubについてはYes。そりゃパスワード入れてますもの。
Google AccountsについてはNo。あくまでもパスワードを入力する先はGoogleになるので、他のサイトは介在できない仕組みです。
以下、Pokémon Trainer Clubについては自明なので言及しません。
Bについて
Yes。
どのくらいの長さの時間使えるかは分からないですが、Access Tokenかセッションのどちらかの有効期限内では、勝手に操作出来るものと思われます。
Cについて
以下、理由を。
まず彼のサイトの認可取得方法は、OAuth2という物にもとづいています。
これは、あるサイト上のユーザリソースを、外部のサイト若しくはプログラムから操作する場合に用いる方法です。
OAuth2自体はオープンかつセキュアな仕様ですが、運用によっては当然危険な事が起こりえます。
よって、Aについては(Google Accountsならば)No。そもそもパスワードを受け渡さないための仕組みだからです。
さてこの仕組ですが、認可を得るための方法は幾つかの手段があります。
ココでは彼のサイトで使っている方法(AndroidアプリやiOSアプリなどのための認可手段)だけを説明しますと、
1. OAuth2 ClientIDを用いてAuthorization Codeを取得
2. Authorization CodeをOAuth2 ClientIDとClient Secretを用いてAccess Tokenに分解。Authorization Codeは一回のみ使用できる(あってますよね？)
3. Access Tokenを特定の場所に投げることで、サイト側はユーザの情報を知ることが出来る
となります。
彼のサイトで用いているアクセス範囲で確認できるのは、ここでAccess Tokenを用いて取得できるのは、Google Accountsのメールアドレスくらいです。
コードをコピーする仕様になっていますが、それは1と2の間で行われています。
もし何らかの手段でConsumer Secretを知っているなら、Access Tokenに分解する作業は彼のサイトで行っている可能性が高いと思われます。
しかし、普通Client Secretはサーバサイドに置き、APIで分解する形が多いと思われます。
分解された後のAccess Tokenは一定期間で有効状態が切れます。
Client IDはある意味オープンな情報なので、コード発行画面までは、知っている人なら比較的たやすく表示させることが出来ます。
よって、「ポケモンGOが」と表示されているのは、このClient IDが本物だから出ているのであって、彼のサイトの作者がそういう詐称行為を行っているわけではないです。
ここからは、Android用のtokenの動きを知らないので推測となります。
Access Tokenは1時間弱の短い期間で有効期限が切れます。
その後のAccess Tokenの取得は、一回ユーザが認可すると再度の取得には認可画面による対話操作を必要としない仕組みを使い、アプリケーション内で自動的に取得できるような実装になっているんではないでしょうか(AndroidやiOSに詳しい方、補足願います
また、Access TokenはセッションやDB内で管理し、クライアントアプリ側には戻さないのがよくある姿ではないかと思います
(ステートフルは重いからとクライアントに戻す実装をしている場合もあるとは思いますが)
よって、通常であればAccess TokenがBはセッション持続中若しくはAccess Tokenの生存期間中の短い時間ならYes。
Cは可能性は低いものの、Access Tokenをクライアントに送り返す仕組みにしてあり、彼のサイト側でそれをDB等に保存してあるならばYES。
となります。
私は基本的にサーバサイドの人なので、クライアントサイドの常識はそーじゃねーよって話もあるかとは思います。
その時は…すいません。と、予め謝っておきます。
