  |
はてなキーワード: コマンドとは
口八丁な人間が立ち上げたこともあり、仕事は目が回るほどある。
しかしタイトル通り、自分以外の全員のマインドがアナログすぎて辟易している。
連絡は全て一つのトークに集約されていて、ログがどんどん流れていってるので、正直どのトピックがどうなってるかが全くわからない。
一度Slackへの以降を提案し使い始めてみたが、数日のうちにLINEで「Slackをチェックして！」と言わなければいけない状態になり、1週間も経たずにLINEに逆戻り。
トークルーム一つでやりとりしているので、発言見逃がしまくり。
Googleカレンダーで予定を共有するなんてことはせず、今度出来上がるおしゃれなオフィスには予定を書き込むためのでっかいホワイトボードが。
そこはオシャレじゃなくていいのかよ。
ウェブを少しでも理解できる人間は自分以外にはおらず（ウェブサイトを「HP」と言ってる時点でお察し）、一番ボリュームのあるウェブの仕事は全て自分に降ってくる。
会社で新規に立ち上げたサービスがあるのだが、申込を社内でアサインするところは全てLINEでやりとりして決める。
サーバとデータベース用意して、Slack / カレンダー / Slashコマンドを駆使するなんてことは勿論提案したところで理解されず。
大きい案件ごとにフォルダは別れているのだが、その下のフォルダには「〇〇_写真1」「〇〇_Photo」「〇〇_JPG」みたいなほとんど同じようなネーミングで中身が全然違うフォルダが沢山ある。
過去のデータを遡ることが非常に難しく、勿論検索をかけることもできない。
日々、こんな具合でもう辞めたいと思ってる。仕事以外の自動化できる雑務を疑問もなくやっている社員ばかりだ。
正直自分一人でもやっていけるし、ウェブの仕事が多い割に、ウェブでは他の社員が全然役に立たないので、仕事の負荷がおかしいこともままある。
オフィスを見回してみるとセカセカ働いているのは自分だけってことも。
ふと疑問に思ったんだけど、ディレクトリ dir に 001 002 003 ていう3つのファイルがあるとして、
（そしてその他にはファイルは無いとして）、
cat dir/* ＞ all.txt
ていうコマンドを打ったら、3つのファイルがつながったファイルができるけど、これって、
001 002 003 ていう順番で連結してもらえると期待していいんだろうか。
ええと、これってコマンドの問題じゃなく、使ってるシェルの問題かな。
Vim81 をインストールしようとして、大量のパッチをあててる時にちょっと疑問に思って。
順番狂ったらおかしくなるかも良くわかってないんだけどさ。
アニメがはじまったついでにPC98版 YU-NOのメッセージファイルフォーマットを解析してみた。
"*.MES"
+0 offset(2byte)
+2 辞書データ(offset - 2 byte) sjis2byte文字のつめあわせ
| 0x06 | 次の0x06までのデータがファイル名 |
| 0x11 | 入力待ち |
| 0xC0-0xCF,0x60-0x7F | 0x20を足して次の1byteを追加すればsjisの1文字になる |
| 0xD0-0xFF | 0xD0を引いて2倍した数値に該当する辞書データの1文字 |
| 0x133003 | 主人公の名前に置き換え |
他にもコマンドいろいろあるみたい
在籍期間は約2年。これは組織に所属する期間として短いものかもしれない。
たった2年である。されど2年。鬱憤が溜まるには十分すぎる時間であった。
新卒採用ページの初年度年収は嘘である。個人的に一番不満のあった点なので最初に触れておきたい。
ヤフーの新卒採用ページを見ると以下のように書かれている（修士の場合）。
私の「初年度」という言葉に対する解釈「4月〜翌年3月の12ヶ月間」が正しいのであれば、この内容は誤っていることになる。
実態から言うと、初年度年収は468万ではなく410万あたりなのだ。
重箱の隅をつつくような指摘と捉えられるかもしれないが、私としては見逃し難い点であったので深掘りしていく。
これが誤りだと主張するに足る最も大きなものとして、初年度の社員は年2回ある賞与のうち1度しかもらえない事が挙げられる。
ヤフーでは4月と10月が賞与月であり、それぞれ基本給の約2.5ヶ月分の賞与（評価によって多少変動するが初年度の変動はなし）となる。
ただ、新卒社員は4月にもらうことはない（仮に6・12月タイプだとしても、通常6月にもらえるのはいわゆる寸志だろう）。
つまり、
(242,000 + 47,266 ) × 12 + 242,000 × 2.5 × 1 = 4,076,192
いかがなものだろうか。個人的に60万前後の差額は無視してよいものではないと思う。
ではここで、上文に書かれている「賞与等」の解釈を変え、残業時間を考慮している路線を考えてみる。
条件として、最初の4〜6月は全体研修で残業が許されていないため、7月から3月の9ヶ月でできる残業時間が対象となる。
また、残業時間が45時間を越えていいのは年6回まで、かつ上限は80時間である。
加えて、初年度の1年間での昇給は基本的になかったので、1時間あたりの残業代は固定とする。
これを踏まえた上で計算してみる。
「25時間相当分の固定時間外手当47,266円/月」とあるので、残業は1900円/時となる。
80時間残業を半年間続け、残りの3ヶ月は45時間の残業をしたとする。
1900 × ((80 - 25) × 6 + (45 - 25) × 3) = 741,000 円/9ヶ月
これを先程の4,076,192円に加えると、4,817,192円である。
なんと、468万を超えた。失敬。
「新卒採用ページの初年度年収は嘘である。」と冒頭で言ってしまったが、嘘つきは私のほうだった。
さて、これを読んでどう感じただろう。
こんなことはよくある、で済ませていいものとは思わない。
（「残業80時間を年6回なら別に苦ではない、むしろこの業界なら当たり前では」といった類のコメントは一旦跳ね除けさせてほしい）
それに45時間を1度でも超えれば上長から指摘を受けるし、6回も超える事例が実際にあるのかと言われれば極めて少数派である。
このような書き方がされていれば新卒1年目にもらえる下限年収のように感じても不思議ではない。少なくとも私はそう感じていた。
これはいつだったか転職ドラフトで炎上していたときと同じ流れだ。
[転職ドラフト経由でY社の内定貰ったけど](https://anond.hatelabo.jp/20160925170021)
正しい情報をミスリードなく伝えるのが企業としての在り方ではないだろうか。
最初の2週間はビジネス・エンジニア・デザイナーの3職種合同で様々な研修を受ける。研修の内容は多岐にわたり、当然ビジネスマナー研修もあった。
研修中初期はPCを開くことを許可されておらず、みんな紙にメモをとっていた。自分はメモをとらなかった。
6人で1つの机にまとめられ、座学の合間にやたらと個人ワーク・グループワークを要求される。特にグループワークが苦で苦で仕方がなかった。
グループワークは、都度いくつかのグループが話し合った内容を発表するよう当てられる。
話し終えると「はい、拍手！」と司会役を務める人事の方が声をかける。そして拍手。
約300人が回答者に向かって一斉に拍手するのだ。時代錯誤も甚だしい。
この研修を通して、付箋とペンに対してアレルギー反応を示すようになった人も多いと思われる。
今年度でもその形式が続いているのであれば退職希望者を増やすだけなので早急にやめたほうがいい。
そして、全職種合同の研修を終えた後はエンジニアのみに用意された研修が続く。
内容は外部講師によるLinux研修・Java研修・チーム開発と
先に言っておくと外部講師による研修は残念すぎた。不要。不毛。不服。
まずはじめにWindows PCを貸与され、それで戦うことを強要される。
一方で、ヤフーでの業務に使う貸与PCはエンジニアならMacのみである。なんということだろう。
そして外部講師企画のチーム開発は「雑に集めたメンバーでハッカソン」というタイトルが正しい（ここでもまだWindowsのまま）。
Linux・Java研修で学んだ内容を活かせる場面は決して多くなく、チーム内の優秀な人がひたすらにリードする形式だった。
チームによってはリードされる側は「なんかすごいのが出来上がっていく（が仕組みはよくわからない）」、リードする側は「この時間に意味があるのだろうか」と誰得な雰囲気が出来上がる。
その後、チーム開発研修についてもフィードバックする機会があったのだが、
とある同僚は
チームメンバーにgitの使い方を教えないといけない場面があった。gitコマンドに初めて触れるような人をエンジニアとして採用するのはどうなんだ
というコメントを残していた。
なかなかに攻めているなと思ったものの、振り返ってみれば全くそのとおりである。
gitコマンド触ったことない=初心者、が必ずしも成り立つわけではないがWeb系業界のエンジニアにはある程度当てはまるのではないだろうか。
同僚のコメントも受け、採用サイドに苦言を呈するのであればクックパッドの方の言葉をそのままお借りしたい。
クックパッドでは、新卒であってもプログラミング未経験者は基本的にエンジニアとしては採用しません。
なぜか？というと、学生のうちにプログラミングやソフトウェア、あるいはサービスを作る事に興味を持ち、それを仕事にしたいと思っているのに、手を動かさない理由はないんですよね。
[クックパッド 星氏「新卒でも技術力を重視、尖ったエンジニアはエキスパート枠として採用」《新卒エンジニア育成カイギ その5》 |](https://blog.codecamp.jp/engineer-training-cookpad-part1)
また、ヤフーが「世界に通用する tech company を目指す」と謳っていることも踏まえる。
今でも不思議でしかたないのは、私の知る極めて優秀な後輩2名がエンジニアとの面談に行く前に落とされてしまったことだ（1人は今GAFAにいる）。
もちろん、面接での受け答えがうまくいかなかったのかもしれないが、それならそれで持っている技術の良し悪しをはかる以前に「面接うまい人材」が重視されていることにほかならない。
技術さえあれば、コミュニケーションがとれなくていいと言っているわけではない。
一方で、面接で落ちたからと言ってコミュニケーションがとれていない、とも思わないが。
ことエンジニアの採用に関して言えば、GitHubやホワイトボードコーディングで見られる技術に関する蓄積や瞬発力、
リサーチャー寄り（機械学習エンジニアなど）であれば関連領域の論文実績等に比重を置いてもよいと思う。
もちろん、採用する側が手を抜いているわけでないことは重々承知している。
ヤフー含め、多くの企業が採用に苦戦していることを鑑みると、採用そのものがとても困難なプロセスであることは明らかである。
加えて、GitHub等を見たとしても応募者の技術力を正確に測ることは難しい。
ただ「世界に通用する tech company を目指す」 のであれば、まず人材の技術力ありきではないだろうか。
ヤフーにはヤフーの採用戦略があり、一個人が偉そうに言えるものではないので（十分語り尽くしているけれど）このあたりで大人しくする。
研修の虚無さについて書いているつもりが、いつの間にか採用云々についてヒートアップしてしまった。
無理やりまとめるならば、研修・採用において間違った方向に舵が切られていると感じた次第である。
ただ多くの人が納得のいかない評価制度は直ちに改善されるべきであり、決して惰性で運用されてはならない。
ここではこの4月に廃止されることになったバリュー評価に触れる
（採用ページからもバリュー評価に対する言及が消えていることは確認済み）。
廃止されたからこそ、この場を借りて言いたい放題言わせてほしい。
一言で言えば、ヤフーのもつ5つのバリューに沿って360度評価を行うものである。
Japanese Traditional Big Company の実施する年功序列よりは億倍まともだし、360度評価といえば聞こえはいいが、
このバリュー評価がきちんと機能していたかと言われれば疑問符が浮かび上がる。
[Yahoo! JAPANのミッション・ビジョン・バリュー - ヤフー株式会社](https://about.yahoo.co.jp/info/mission/)
謎だ。
やはりわからない。
重複しているようにも感じるし、「やりぬく」あたりはもう一つのパフォーマンス評価（説明は割愛）が担っているようにも感じる。
各々によって解釈も異なるはずである（もし社員で認識が合っていたのであれば今すぐに全力で謝罪する）。
加えて、昇給額の上限がある程度決まっており、いくら成果を出そうと結局のところ全社的にはそこまで大きな差がつかないようになっていた。
本当にとびきり優秀でなければ従来の枠組みを越えることはない。
先輩社員も口をそろえて言っていた。
給料を大きく上げるなら転職したほうが早い、そして数年経ったら戻ってこればいい、と（実際、自分の場合は550万 → 700万前後の転職となった）。
これはおそらくヤフーに限った話ではなく、転職による給与ハックがWeb界隈全体に蔓延っていることに起因するので仕方ないともいえる。
閑話休題。
いろいろな経緯のもと、この4月より廃止となったバリュー評価。
今ではパフォーマンス評価のみになったが、やはり評価に対する不満の声はいくらでも聞こえてくる。いくらかマシになったのかもしれないがやはり難しい。
世はAI時代。院卒の新入社員は、多くがデータサイエンス部署なるものを志望していた。
学部卒でも志望している人は少数ながらいた。
しかし蓋を開けてみると、ほとんどはデータサイエンスに全く関係ない部署に配属となった。
データサイエンスの部署に限って言えば、一番必要なのは東大もしくは京大を出ているか、そうでなければ運である。
配属先のハズレを引いた場合、待っているのは市場価値の大暴落。
こればかりは巨大な企業なら日常茶飯事かもしれないが、現実を受け止めるには時間がかかるものである。
最後に、社外の人から見れば些細なこと、しかし多くの社員が日々思っていることであろう不満で締めてみたい。
毎朝絶えること無く形成される長蛇の列、まさに地獄絵図。阿鼻叫喚とも言える。
ヤフーでの出勤の定義は「執務エリアに入り社内Wi-Fi下で打刻アプリを起動しボタンを押下」である。
これを10:00までに行わないといけないのだが、入り口のエレベータまわりでは9:40あたりから徐々に変化が現れる。
気づけば、建物に入ってから執務エリアに着くまで10分以上要することになる。
つまり、この行列の待ち時間も計算に入れて通勤しないといけないのだ。
これを毎日経験するのは気が滅入る。ただでさえ電車通勤で疲弊しているというのに。
もっと余裕をもって出勤すればいいのでは、という声もあるだろう。ごもっともである。
しかし、時間をずらせばずらすほど電車の密度は増加してしまう。
これもできるのであれば避けたいし、個人的にはエレベータ行列の方が鉄の箱にすし詰めされるよりマシであった。
では、徒歩圏内に住むというのはどうだろう。
これも金銭面で相当にきつかった。
仮に自転車圏内だとしても、私の求めた最低限の生活（風呂とトイレに行きたいときにいける）を送るには80,000円を軽く超える。
家賃は手取り月給の1/3程度が目安とよく言われているが、就職を期に上京してきた自分の金銭感覚からすると家賃に80,000円を払う決断は最後までできなかった。
そして近くに住んでいたとしても、電車通勤から解放されるされるだけで、早く出ないのであれば結局エレベータ行列に悩まされることになる。
ということで、この燦々たる状況に対する企業側の動きにも触れておきたい。
結論から言うと、行列に対する直接的なアプローチは何一つ無かった。
どこかのチャンネル（≠slack）で議論されていたりもしたが「待ち時間に何か楽しめるものがあればいい」というのもあり、まったくもって根本を解決していないなとなった。
うまくたとえられているかわからないが、「料理が不味い」ときに「美味しく感じられるよう空腹にさせてやる」というものが近い。
唯一の救いは、月5回まで利用できるリモートワーク制度である。
が、ヤフーはリモートフレンドリーであってリモートファーストではないし、みんながみんなリモートワークに慣れ親しんでいるわけでもない。
加えて、エンジニア・デザイナー職だろうとマネジメント業務を担い始めた途端にリモートワークは難しくなる。銀の弾丸ではないのだ。
話が発散しているが、エレベータ行列が極めて悲惨なものであった、言いたいことはただそれだけである。
当然である。がポジティブな面は調べてもらえればいくらでも出てくるので割愛する。
様々な制度はメディアで幾度となく取り上げられているし、給与についてもvorkersや有価証券報告書をみればだいたいわかる。
優秀な社員もたくさんいるし、サービスの規模的にもやりがいを感じられる場面は多いはずだ。
そして、悪いところをずっと放置し続けるような企業でもない（と信じている）。
まとめるにも思い思いに書きなぐっただけなので特にメッセージもない。
煽りに聞こえてたなら申し訳ない。確かに余計なことを書いたけど、ユーザからの入力を受け付けるシステム（ここでは増田）ではコマンドに使われるような記号は安全のためエスケープされるということをすぐに理解するのは無理でもいつかわかるといいと思って書いてしまった。
下手にジャンプを書いたらコードはスパゲッティになるとか書こうかなーとは思ったけどスルーした。それに関数周りの話はもっとコンパクトでよかったね。
最後に、Rubyを選択したのは日本語で問題が滅多に出ない、その一点。Pythonも3ならまず問題ないと思うけど、2系は割と問題が出る。もうみんな3系に移行してると思うけど、もし2系を使ってしまう罠があったらと思った。Macで最初にインストールされてるpythonも2.7だし。
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓からCUI（コマンドユーザーインターフェース）でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。（追記 すごく間が抜けてたけどMacOSXはUnix系OSです）
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou ＞ aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか？とりあえずやってみよう。ここで＞は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。（追記 ブコメ指摘感謝）
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか７割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
（追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました）
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF（エンドオブファイル）とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
（追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います）
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか？こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
（追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです）
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
○朝食：ピザトースト
○調子
まあ昨日怒られたのも、このやる気がない感じが原因なわけだし、ちゃんと向き合えないなら休んだ方がましかな…… って。
お休みってか、まあもう言葉を選ばずいえばサボりました、サボリーマンです、ユマ・サーマンです。（ユマサーマンではない）
特に、安眠のためのオナニー、安眠オナニーじゃない、ガチのやつはなんか久しぶりにした気がする。
いや、ラジオネーム安眠さんでオナニーすることじゃなく、寝付けない時にするやつね。（いやラジオネーム安眠さんでオナニーすることを安眠オナニーと言うわけがないだろ（ラジオネーム？））
文章を読むゲームは好きで、かつミステリはもう大好きなジャンルなので、前々からプレイしたかったので、このサボりをきっかけにプレイ。
かなり「ベタ」な内容だったけど、キーレスポンスはいいし、イライラするようなコマンドの深さもないしで、楽しくプレイでき、一気にクリアまでプレイ。
ストーリーも、ミステリというよりは、サスペンスなノリだったけど、十分面白かった。
こういう王道な作風好きだなあ、仕事サボってまでプレイする価値があったか？ と聞かれると言葉に詰まるけど、まあ楽しい休日を過ごせたから良しとしたい。
○ポケモン青（3DSVC）：悪ポケないし、それに準ずるポケ縛り
タケシの突破方法は、しっぽをふるゴリ押ししかなさそうなので、コラッタをもう一匹ぐらい育てとこうかなあ。
今日は上に書いた偽りの黒真珠をプレイしてたので、あまりプレイできず。
まだトキワのもりにも入ってないので、そろそろ挑もう。
っていうか、これ深く考えずにこの縛りで始めたけど、どういう捕獲順なんだっけ。
コイキングがお月見山の手前、ニャースが育て屋の前、イーブイがタマムシ、ベトベターがグレン。
うーん、タケシとカスミさえ越えれば、ギャラドスとペルシアンでスムーズに攻略できそうかな。
○グラブル
それと、よわバハをソロで倒してみたりしてた。
他のうだつの上がらないゲームストリーミングサービスと違ってワンチャンあり得るのは
数多のビジネスマーケットを焼き払ってきたGoogle様の得意技「ダンピング」が炸裂するかどうかが不明だから。
無料は厳しいにしても、データを囲うためにコストから考えてあり得ないレベルの低価格で攻める可能性は無くはないと思うので
もしそうなったらゲームストリーミングサービス市場を焼き払って覇者になるかもしれない。
ただ、正直そこまでしてゲームの進め方に関するデータを囲う意味があるかというと、頭の悪い俺には無いように見えるので、可能性は低いんじゃないかな。
今のAIの盛り上がりに浮かれてる人達は「スゲェ！」って言ってる人も居るけど、そのAI育てるためにはデータ喰わせて調教する必要があるが、ゲームの進捗に関するデータの保持形式が縛られて開発側に余計な面倒が増えないかというのが少し気になる。
AIに喰わすためのデータはキチッとフォーマットそろえる必要があるから、ゲームの進捗に関する部分とは相性悪そうな気がする。
既にわかりきってる事とはいえ、スピードの早い対戦系のコンテンツは絶望的。
でも、コマンドバトルのRPGとか、ターンベースのシミュレーションとか、比較的理想郷が近いタイプのゲームもあるのでモノによっては入力遅延より場所を選ばずに遊べる利便性が勝る場合も結構ありそう。
でも、グラフィックなり内部処理なりが高負荷のかかるコンテンツでないとデバイスからの解放のメリットが薄いので、そのフィルターも合わさるとゲームストリーミングサービスのメリットがデカいコンテンツの幅はかなり狭まるのが難点。
そして何よりこれ。どんなに大々的に発表されたって、メンツのためにズルズル延命させることがないGoogle様のご機嫌伺いながら金払える人がどれほど居るのか。
いくら世界中にDC建てまくってもリソースは有限なので、社内政治に負けて金引っ張れない、みたいなことにならないのかな？ってのが心配。
まぁ、それほど活発に遊んでいたわけではないのだが、一応それなりに遊んだ身として雑感を。
敵を倒して手に入れた装備をドリップでちまちま強化していくのが楽しかった。
プログレッシブナイフ+2のためにサキエルを狩り続けたりしてた。
キャラのサイズがエヴァとかゴジラとかくらいあるの、必然性は謎だけど良かった。
連打ゲー。自分のターンはひたすら画面を連打（正確には高速スワイプ）し、相手のターンはタイミングよく画面を長押しする必要がある。
熱中するほど複雑ではなく、ながら作業できるほど単純でもないという微妙なところで作業感がすごい。
塗れるのはその場所に行ったはじめの一回だけなので、通勤ルートとかではあまりやることがない。
そのため、実際にはあるきまわらずにひたすらとなり塗りするゲームになってる。
・となり塗りで塗ったところのとなりも塗れるので、無限に塗っていける。
・TTP（テクテクポイント）というポイントを消費するが、TTPは遊んでるとアホほど貯まるのでコスト感はない
・便利なのだが、便利すぎて、実際に歩くよりとなり塗りでガンガン塗ったほうが効率的になっている。
・主人公のアバターがキモかわいいモンスターを倒し続けるゲームなので、キャラ萌えはない。
・アイテム所有枠の増加。アイテムはすぐいっぱいになるので。。。
とりあえず件のアレやコレは
・ブラウザで実行されるJSには必ずサンドボックスが実装されている
それに対してワイが「それは無いんじゃねーの…そんなのブラウザの実装に依りけりじゃん…」って言ってるのがこのtreeやで。
ブレンダン・アイクが上記謎前提について「this is truth.」なんて言うはずないだろ。
補足しておくと
・JavascriptでOSを操作しうる実行プログラムはヘタしたら小学生でも作れる
・Javascriptは紙に書かれたシミにしか過ぎず、それを解析実行するエンジンについてはベンダーにより仕様も動作もまちまち
・ブラウザ以外で実行できるJavascriptもある。wscriptコマンドとかで実行できるんだって。へー。
・「サンドボックスモデル」なんて謳ってるブラウザのベンダーっていなくね？ （セキュリティは謳っていても）
ってことな。
