結局VanillaJSである。
上記のブログに刺激されて私もフロントエンドというかJavaScriptに対する思いを綴ったポエムをば。しかし、なんか書くのダルいので、大分大雑把にかくぞ。
さて、さっそく結論を述べよう。今のフレームワーク論争やらに対する解決策はVanillaJSを使うってことである。
フロントエンドSPAのフレームワークについて
まず、今のほとんどのフレームワークが使えないってのはそのとおりである。その話してみよう。その理由は、「フロントエンド」 ってのは一括りにできないからである。「ハッカーと画家」のとある言葉をアレンジして言えば「フロントエンドはユーラシア大陸のようなものである」。フロントエンドが関わる範囲が大きすぎるのである。ヨーロッパもあればアジアもあれば中東もあるという感じである。
範囲が大きすぎて、フレームワークとして扱えるほど技術が抽象化できないのである。だから、そもそもすっげーReact+Reduxに乗っかれるところもあれば、そうでないこともある。フロントエンド一般じゃなくて、もしそれがSPAの範疇だとしても、SPAのすべてのプロダクトで抽象化できない。というか、できていないと言った方が正しいのだ。
フロントエンドで難しいことやろうとすればとことん難しくできるし、フロントエンドで簡単にやろうと思えば簡単にやれる。だから、複雑なところたとえば、フロントエンドSPAやらであれば、フレームワークのことやAltJSやTypeScriptを考える人が多いだろうし(僕はそれでもVanillaJSで書くのだが)、そのクライアントのところでゴチャゴチャしないんだったら、jQueryとかでいい(僕はそれでもVanillaJS…)という考えもいるだろう。
また、フロントエンドのSPA自体の話を考えてみると、あれはフロントエンドでGUIをちゃんとやろうとすることだと思っている。そしてGUIは難しい。
GUIは難しいってのは、僕はツイッターとかで何度も言ってきたと思うけど、改めて言うと、まずその非同期性、GUI のアプリケーションや操作などの状態管理、ユーザ行動の非決定性、そして速度やらと戦わないといけない。また、そのUIデザインと実装を分けて考えることはできない面もある。インタラクションをきちんと考えると難しい。
そのようなGUIに大して設計、実装技術の歴史はあった。GUIの設計や実装の歴史を調べてみると、実際に昔から発展してきた。しかし、Webが台頭してくると、GUIの文脈は引き継がれず、Webが独自に発展していった。そうして、フロントエンドSPAの時代になり、またクライアントサイドMVCであったりとかフロントエンドはそういった議論になっていった。僕から見れば、それらは、昔のGUIの設計や実装技術をやりなおしているようにしか見えなかった。
だから、
ウェブフロントエンドの技術の進歩と興亡の速度には目を見張るものがある。
ということに大しては、違和感しなかくて、そもそも既視感がありありとあって、「進歩」しているようにはまったく思えなかった。(ただ、その中でも、WebのSPAだから出てくる問題もあってそこは、今までに無かったことはあった。)
また、フロントエンドSPAのフレームワークを見ていくと、僕にはただのWebアプリの延長としてか考えてない人達が多くて、そもそもGUIとしての実装を思ってない人が多い。だから、そういう人達と議論しても議論がまったく噛み合わないことが多い。サーバーサイドレンダリングをしたいだけの人達が多い。そのUIやらインタラクションを考えずに。だから、はっきり言っておこう。当たり前なのだが、フロントエンドとバックエンドの技術は異なるのだと。
まずその人達と会話すると「フレームワークの選定」から始まる。僕としては、おいおい、なんでいきなり、「どのフレームワークを使うか?」になってるんだ、いきなりフレームワークに乗っかる前提になっているだ? という思いになる。まず、設計の話をしろよと。設計してから、フレームワークをどのフレームワークにすべきか、そもそも使うべきか使わないか、などを考えるべきである。
さっきも言ったがフロントエンドはバックエンド程抽象化されてないのだ。だから、「デファクトのフレームワーク」だとか、「無難なもの」なんて無い。もちろん、僕はフレームワークをつかうなと言っているわけではない、いろいろ設計した上で、フレームワークにのっかれると思えば乗っかればいいのだ。しかし、設計もなくフレームワークにただ乗っかると、結果、フレームワークの設計と、自分たちのアプリケーションが合わないなんてことが多発する。そういう人達をたくさん見てきた。
僕はVanillaJSを使う。「VanillaJSを使う」という意味は、まず設計から始まるってことを言いたいのである。フロントエンドSPAについて必要なのは設計である。設計した上で、その「プラグイン」として、フレームワークやライブラリを利用するのだ。
また、おすすめしたいのが、フレームワークの実装を読むことである。また、フレームワークを自作してみよう。そうすると他のフレームワークの実装がより理解できる。自作した上で、他のフレームワークを利用することも多々あるのだ。むしろ、そのお陰で上手い乗っかり方が分かる思う。
「デファクト」に頼るな。JSの「トレンド」「デファクト」ってのは、多数の人達が「使っている」にしか過ぎない。JSの人達は、すごい人達ばかりじゃなくて、阿呆もいる。玉石混合なのだ。「デファクト」は単純にマーケティングが上手くいったとかしょうもない理由でデファクトになっていることが多い。だから、デファクトのフレームワークが一番素晴しいなんてことないし、安定しているなんてことはない。むしろ、安定していないからこそ「トレンド」がコロコロ変遷するのだ。
「トレンド」がコロコロ「変遷」する。と言った。ここで、僕は「進歩」したとは言ってないことに注意したい。トレンドが変遷することと、フロントエンドが進歩したを同じではないのだ。言うが、フロントエンドの技術はまったく「進歩」していないと思う。トレンドが変化しているだけなのだ。
jQueryじゃなくて、なぜVanillaJSなのか?
さて、jQueryを使い続ける、って結論の人達が多いのだが、僕はjQueryを使わない。というか使う必要が無いと思っているのだ。
以前、
なんてVanillaJSの入門記事を書いたのだが、そのコメントで書いたことを引用する。
たとえば、jQueryは速記記法であり、また、ブラウザ間の違いを吸収したJSのライブラリで、以前はデファクトスタンダードなライブラリで、DOM APIを学ばずjQueryだけ学習するということがことが起っていました。しかし、その分オーバーヘッドもあり、また、HTML5になり、ブラウザ依存度が低くなり、DOM機能も便利になった今、「jQueryが前提」という考えはとても技術的選択の視野を狭くする、もったいないものです。そもそも、フロントエンドエンジニアであるならば、DOM APIは知っておくべきじゃないでしょうか。
ということである。
もちろん、既に書かれたjQueryのコードを今更Vanillaにしろなんてことは言わないし、たぶん僕もそんなことはしないような気がする。しかし、今後フロントエンドのコードが肥大化するのであれば、まずVanillaにすると思う。
「脱jQuery」というのは、多くの人達は「フレームワークの利用」を考えるだろうが、僕は文字通り「jQueryをつかわないようにする」ってことをやると思う。「jQueryもなく、そこに設計されたVanillaJSのコードがあるようにする」ってことである。そうした上で、フレームワークの利用を検討するというのは考えてもいい。
ぺちぱーエンジニャーからのフロントエンドに対する思い - 虚無愛好部活動記録 こちらのほうで
結局jQueryはVanillaJSの便利なラッパーでしかなく、つらいつらいDOM操作の悪夢に悩まされるのはJavaScript使う以上どれでも変わらないでしょう。それなら記述量の減るjQuery使えばいいじゃん派です。
僕としてはjQueryを使っても、記述量はそこまで減らないし、DOM操作をするんだったらそもそも、VanillaJSでええやんって感じだし、なので、jQueryはVanillaJSの便利なラッパーではない。という意見である。「お前のなかではそうなんだろ」と言われそうではあるが。
設計しろよということ
結局僕は、jQueryも嫌ってはいないし、フレームワークを嫌ってはいない。設計されてないゴチャゴチャしたコードが嫌いなだけなのだ。
本来、ソフトウェアエンジニアである以上、設計することは当然なのだが、何故か、サボっている人達が多いのだ。サボってサボってサボりまくって、コードをごちゃごちゃにしている。本来であれば考えないといけないことを、考えずに過ごしている人達が多いのだ。本質的なことを考えずに、最新のトレンドだからだとか、騙し騙しコードを書いているのだ。
書くの疲れたので辞めにする。ああ、僕も丸くなったものだ。
@nobkz 丸くなったのぶかずさん、、、大人になるってザンコク、、、
— インターネットも届かない闇 (@no_maddo) 2017年5月5日
【Re:】 プログラミングの学び方がわからない 「なぜ勉強してるの?」
を見て。思ったことをつらつら。そこはかとなく書きつくす。
んで、まず、全般的に読んでて。なんで「勉強してる」のかがよくわからない。つらそうだなと。それはまた後で書いておくとして、
最後の、
何を学習したらいいのか本当にわかんない。 迷宮にいる感じ。
とかは、学習したいことからやればええんじゃないのとか。
その学習するべきことがまだまだ沢山あるってことだろうけど、良いことじゃんとしか。僕も勉強すればするほど、勉強するべきことが増えて、時間がどんどん惜しくなる。あれもやりたい、これもやりたい。だから、たぶんそれと同じ状況だろうと。
まーけど、僕は、そのたとえばAをやるからこれこれを学習するみたいな目的がちゃんとあったり、単純に楽しいからこういうのを勉強したいなーってのがあって、特段ね、何を学習しようか悩むことはなかった。いや、悩んだんだけど、わりと整理すれば選択しやすかったというべきだろうか。
例えば僕の場合は、エロゲ作りたかったから、プログラミング始めたし、そしたら何故かLISPを出会って、LISP楽しいマンになって、ずっとLISPを勉強したし、LISPが素晴しいと思うために、いろんな言語勉強したし、Haskellやってでやっぱり型は必要だよなぁとか思ってTaPL読んだりしたし、なんでShenは神なんじゃないかと思って楽しんだし、とかいろいろ。
コミュ症がフランス語や英語やドイツ語覚えても、使う機会がないとまったく価値がないと思う。
あと、プログラミング以外にも、ドイツ語と、スペイン語は使わないのに、勉強しているし(楽しい)。
だから、
ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。
っての、そんな考えもあるんだなぁと、なんか無駄に関心してしまった。僕はなんか、言語覚えることに、意味を考えたことがないからね。楽しいというか、もはや日課という感じにもなっている。
でも、まぁ、その勉強する意義を考えておかないとダメなのかなぁとか思ったりするし、それは僕の課題でもあるのかなとかね。
あと、言語をあれこれ勉強するのと、一つの言語でガッと勉強するのどっちがいいとも言えない。ただ、どっちもやったほうが良い気もするし、どっちもやれば、もっと楽しくなるとは思う。ちなみに、僕は自覚として、一つの言語に執着しなさすぎる感はあるな。ただ、一つの言語ばっかりやろうとは全く思わないのだが。仕事だったら仕方なくやるけどね。
パソコンのスペックもどのくらいのものを用意したらいいのかわからない。 10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない。
とりあえず、どのぐらいのスペックが良いかは、いろんな人の意見があると思うのだが、一致しているのは「良いの買えよ」ということだと思う。メモリは最低でも8GBは用意しようとかね。プログラミングを勉強するってのは、少なくともコンピュータを使って学ぶことでもあるんだから、それなりに自分で考えて、自分のマシンに拘りを持ってほしいなぁとか。
Emacsはええぞ。
広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。
paizaは気にしないほうがええんじゃないのかねぇ…とか思うんだがまぁ、本人が気にしているからなぁ。あと、深く行きたいって思うのは素晴しいけど、結局のところ、広く浅くと、狭く深くって議論って僕の結論として「深く行くには結局広くならなければならない」ということなんだよね。僕の知っている、なんかすごい深いことをやっている人ってのは、なんだかんだ、広いんだよね。たぶん海なんだよ。広くて深い。
何を学習したらいいのか本当にわかんない。 迷宮にいる感じ。
結局また、ここに戻るけど、何を勉強するべきかってのは、その人が何を勉強したく、何を勉強するのかは自由だし、勉強したいのからやればと思う。やっぱり、その辺は自分で整理して、勉強したいものからだとか、目の前にあったからだとか、ふと思い付いたから、勉強するしかなくて、あとはとにかく手を動かして、ウンウンやると楽しいと思う。
そういえば、そのあるエンジニアのブログとか見てると「世界のエンジニアは成長しているのを考えると… 」見たいな危機感を持っている方々がいて、なんか競争みたいにして、勉強する人達はいてすごいなぁとか思う。そういう考えをもって勉強することねぇからなぁ…。というか人と比べると、僕もまー、天才でもなんでもないから、たぶん辛くなっちゃう。辛くないのかね?分かんないけど。僕は他の人とくらべると負けまくってると思うからね。
なんで、「人と比べて、人があれやっているから勉強する」ってのはたぶん辛くなるのでやめた方がいいと思うよ。やりたいならいいけどさ。あんまり人と競争しない方が良いかなぁ。Haskell書いている女の子がかわいかったからその子にモテたくてやるとかだったら楽しいんだけど。
まぁ、ひとまず、良いマシンを買うところからを勧めるかなー。
時間があっても...
心に余裕がねぇとブログなんて書けねぇ。
「けものフレンズ」を5話まで見て
最近、けものフレンズをバンダイチャンネルに会員登録しいて、Apple TVで見てるのだが。これは面白い。ので今の気分を綴って行こうと思う。そもそも、基本的にレビューをブログではしない人間だが、今回は「なぜ面白いか?」ということをずっと考えているので、とりあえず、今の段階の考えを残したいと思っている。また、他の人は「つまらない」ということも言っていて、わりと評価が分かれている感じもしている。その人たちにも、見ろと言わないが、僕が面白かったと思う理由を共有しておければいいかなーとか考えている。
僕は、そもそもオタクにしてはアニメをそこまで見てない方で、一般人からしたらアニメを見てる方だとは思う。つまり、ニワカアニメオタクと言えはそうかもしれない。まぁ、twitterとかで話題になっているアニメを視聴するぐらいの人間だ。
そして最近そのtwitterで話題になっているアニメとして「けものフレンズ」があった。TL上がなんかひらがながおおくなって「すごーい」「たのしー」とかなっているのを目の当たりにして、「けものフレンズおもしろいの?」って思って,視聴した。
嵌った。すごーい。おもしろーい。となった。 いや、まぁ、その「すごい面白い!」というよか「良いなぁ~」という感じ。
あとあと調べて、1話が面白くないという評価がたくさんあったが、僕は1話はそんなに抵抗なく、むしろ楽しく見ていた。「どこがつまらないの?」という感じだったが、「時間がゆっくり流れる」というのがなるほど、間延びしてつまらないのかなどと考えている。僕はむしろ、そのゆったりとした感じが良かったように思う。
そのあたりは、「ごちうさ」 と似たようなものを感じていた。ごちうさは「日常系」? というらしいが、おそらくけものフレンズは「日常系」という分類に入らないだろう。しかしながら、あのゆったりとした時間を流れている感じは、「ごちうさ」と似ている間隔がある。
ちなみに、シャルちゃんがごちうさの中でいちばん可愛いと思う。
よくよく考えると、けものフレンズの女性的なキャラクターが多い(女性的と言ったが、はっきりとした性別が分からん)。それがある意味、「性的」なことを排除していて、「フレンズ」の意味合いを強くしているのかもしれない。他人に興味を持ち、それを尊重する、ある意味理想的な世界を強調するのかもしれない。
世界の話をしたので、世界観的な話をしておこう。というのも、僕としてはそもそも、けものフレンズが面白いと思う理由がその世界観にあるように思えるからだ。その世界観のおかげで、「けものフレンズ」の独特な雰囲気、空気感があるように思える。2話からおもしろくなるというのは、そのあたりがだんだんと感じてくるからだろうか?
けものフレンズの世界は、「終末後感」を感じるのである。物語の始めの方を見てるだけだと、われわれの住む世界とはまったく別の、「つながってない」世界のように感じるが、物語が進み、かんばんやパンフレットやパークの入口的なところ、道路、バスなどの、我の世界に存在しうる、人によって作られるような造型物などや、物語の「フレンズ化」や「けものだったころ」などの台詞などから、人類が居た世界に急につながってくるのだ。
その中で「かばんちゃん」はヒトのように思えるが、サーバルや他の動物はそれを「ヒト」と判断できていない。しかし、物語ではヒトが過去に存在したのかという描かれかたをしている。ということは、ヒトはいなくなったのだと。ヒトが滅亡したのかと。
我々の住む世界と繋がっていて、そして、その人類がいなくなった後の世界である。僕はどうしても自分たちの世界と対比せざるを得ない。あの世界のけものたちのあり方は、理想的に感じる。自分たちの世界はどうだろうか? 「人類がいなくなったら、世界は良くなったよ!」みたいにも取れそうである。
ちなみに、過去の僕が見たアニメで近いなと思うのが、「人類は衰退しました」である。
だた、このアニメと「けものフレンズ」で違うのは、これは、「終末期」であって、「終末後」ではないということである。人類は衰退している途中ではなく、既に滅亡した後の世界が「けものフレンズ」であるように思う。
また、このあたり「がっこうぐらし」の1話を延々と続けている感もあるのが、「けものフレンズ」である。世界観がそうだというより、その雰囲気がである。
「狂気」を感じるのである。その狂気があの「けものフレンズ」の独特な面白みであるように思える。あと、狂気といえば、あのどうぶつえんの、おにいさん、おねえさんの、解説もある意味狂気である。毎回の楽しみである。
だいたいそんなところだろうか?
久し振りにアニメを見た。このアニメは最後まで視聴しようと思う。最後まで見終わったら、また記事を書くかな。
けものフレンズ。すごーい。たのしー。
QiitaのAdvent Calendarの削除の件について。
qiitaの運営により「ポエム advent calendar」が削除されるため、折角書かれたのにもったいないと思い、こちらに記事移動しました。https://t.co/3VtWgNwQ2s @a_suenami @mzyy94 @unsolvedprobrem @mesaka
— はなだのぶかず@lispはいいぞ (@nobkz) 2017年1月11日
先日、Qiitaのポエムアドベントカレンダーが、運営により削除されたので、そのことについて、思うことがあったので書いておく。
「ポエムアドベントカレンダー」が削除されてしまったことは僕自身は仕方ないとは思っている。というのも、「Qiitaは、プログラミングに関する知識を記録・共有するためのサービス」という主旨があり、僕自身の主観ではほとんどの記事がプログラミングに関するか?と問われてそうで無いと言われたら、そうかもと思うような記事ばかりであったとは思う。ただし、決してプログラミングに関しないか?と問われれば、遠いが全く関係しないこともないとも思えてしまうのもある。「エンジニアの姿勢」みたいな記事とかね。
しかし、アドベントカレンダーの削除自体が適切であったか?と言えば、疑問を投げてしまう。第一に、削除するのであれば、カレンダー自体を削除するのではなく、記事を削除なりするべきでは無いだろうか? Qiitaで書かれた記事であれば、Qiita側その辺はコントロールしやすいだろうし、Qiitaじゃないところで書かれた記事であるならば、リンクを削除してしまえば良いのだ。そもそも、Qiitaアドベントカレンダーなのに、Qiitaで書かれた以外の記事でもアドベントカレンダーに登録できること自体はどうなのだろうか?
第二に、削除基準に関することである。「Qiitaは、プログラミングに関する知識を記録・共有するためのサービス」と謳ってはいるが、その「プログラミングに関する記事」ということ自体、定義が曖昧では無いだろうか? 何を根拠として、「プログラミングに関する」とするのかというあたりについては、僕としてはサービスコンセプトからして、基準を作るなり、定義するなりして、明確化しておくことは重要では無いだろうか? 今回の削除の件で僕が正確に理解できることとしては、Qiita運営側が期待する「プログラミングに関する記事」じゃないことであって、ではQiita側が期待する「プログラミングに関する記事」というのは何か? というのは明確では無い。利用規約(https://qiita.com/terms)や良い記事を書くためのガイドライン(http://help.qiita.com/ja/articles/qiita-article-guideline)を読んでみたが、「プログラミングに関する」定義や基準に関係する記述が見当らなかった。
その上で、利用規約9条7項はちょっと酷い気がする。
当社は投稿内容を当社の裁量で自由に保存することができるものとし、当社が必要と認めた場合には、投稿者の承諾を得ることなく、保存されている投稿内容の削除または修正を行う場合があります。ユーザーはこれについて一切の異議をとなえないものとします。
余談だが、他の記事において、ただのQiitaユーザーが他のユーザが書かれた記事に対して「これはQiitaに適さない記事である」と言う場面を見たが、そもそも、その「Qiitaに適した記事」かどうかは、Qiitaが判断することであって、他の人がするものでは無いとは思うのである。「qiitaにポエムを書くな」というのもQiita側が「プログラムに関係する」とすれば、別に何ら問題は無いと思うし、そもそも「ポエム」であっても「プログラミングに関する」ことは書けるものだとは思う。というか、大抵の技術的な記事はポエムだ。
まぁ、「Qiitaは、プログラミングに関する知識を記録・共有するためのサービス」というコンセプトは良いとは思うし、それをサポートする機能は良いとは思っているが....
エンジニアの「ツミホロボシ」
本エントリーは、2016年度、ポエムアドベントカレンダー2日目です。
ボードゲーム会に参加したりすると「ツミホロボシ」という単語を良く聞きます。意味を聞いたらなるほどなぁ、と思いまして、そして、それは実はエンジニアにも通じるものがあるかなと思いましたので、そのところの思いをぶつけていこうかなと思います。
ボードゲーマーの「ツミ」
初期の頃のボードゲーマーにはあまり無いことだと思いますが、一部のボードゲーマーは「ツミ」を日々重ねてしまったりします。僕も日々「ツミ」を重ねてしまっています。
ボードゲーマーは「ツミ」を放置してはいけません。放置しておくと、どんどん「ツミ」が増えて酷いことになります。その「ツミ」を償わなければなりません。「ツミ」を滅ぼさなければなりません。
なんか良く分からないでしょうか、打ち滅ぼした「ツミ」を「ツミ」上げてみました。
そう「ツミ」というのは、未プレイのゲームの事を指します。ボードゲーマーにとって未プレイのゲームを「ツミ」上げることは「ツミ」なのです!
エンジニアの「ツミ」
一部のエンジニアもまた、「ツミ」を重ねてしまいます。エンジニアの「ツミ」というのは、それは技術書です。
なぜエンジニアの「ツミ」も悪いことです。なぜ「ツミ」は良くないことなのでしょうか?
技術書というのは、その分野において自分自身にない知識や発想、視点、考え方を得る体験です。それは、エンジニアは日々問題解決しているとは思いますが、その技術書持って得られたものは、日々の問題解決に非常に有用なものです。つまり、技術書を読むということは、自分自身の問題解決へのアプローチの選択の幅を与え、時には問題の理解に深みを与えます。また、解決できなかった問題を解決できるようになるかもしれません。
そのような中で、技術書を未読として「ツミ」上げてしまうということは、日々の問題解決を選択肢の幅を失ない、問題の理解が浅いもとのなり、本来解決できた問題が解決できなくなってしまうかもしれません! ああ、 なんと「ツミ」なことか!
さらに不幸なことに、技術書には有効期限があるものもあります! 3年、4年経ってしまうと、償えない「ツミ」になってしまうかもしれません。
エンジニアの「ツミホロボシ」
エンジニアの「ツミ」は滅ぼさなければなりません! ではどうすれば「ツミホロボシ」できるのでしょうか?
ひたすら手当たり次第「ツミ」を滅ぼしても良いでしょう。しかし、そのような真っ当な方法では「ツミ」は滅ぼせないかもしれません。
「ツミ」を滅ぼすには、あなた習慣を変えなければなりません。その習慣が「ツミ」を生み出しているのですから。その習慣を変えるということは、普通の人間にとっては難しく、「三日坊主」という言葉もあり、容易にはできないことです。
「ツミホロボシ」の習慣化について、語りましょう。まず、第一に、「いつやるの?」「今でしょ!」ということです。自身の「ツミ」に気づいたなら、直ぐに「ツミホロボシ」を実行するべきなのです! 「明日かやる」ということは「やらない」ということと同義であることを覚えておきましょう。
第二に「時間をつくるために、ライフスタイルを変える」ということです。ただ、いつもの日常の時間の中にどこかに「贖罪時間」を作るだけでは、不十分です。いつものライフスタイルだからこそ、「ツミ」なのです。たとえば、仕事から家に帰って「ツミホロボシ」をしようと考える方が多いでしょう。しかし、実際には、仕事から帰った時には疲れてしまい「ツミホロボシ」できないとか、深夜に「ツミホロボシ」してしまい、翌日は寝不足だとかという状態になりかねません「ツミホロボシ」のためには、そのライフスタイルを修正しなければなりません。時間を作りましょう。てっとり早く時間を作るのには、「仕事」を犠牲にして良いかもしれません。なぜなら、仕事の生産性を上げる結果につながるからです。上司を説得して仕事中の勉強、読書を認めてもらったりしても良いでしょう。もし認めてもらえないとかであれば退職すると良いですね。
第三に、「場づくり」です。これは、どういうことかと言えば、人間は一人で読書するのはツライものもあるかもしれません。その場合、複数人で、あつまって「ツミホロボシ」すると良いですね。なにかイベントを開いても良いでしょう。エンジニアは一人で勉強する方々が多いですが、複数でツミホロボシするとすごく「ツミ」をつぐなう効率が上がるかもしれません。また、そういった場をつくることによって、読む意思が高くなったりします。「場づくり」のコツを教えましょう。その「場で読む」ということです。事前に読む課題を課すなどをしてしまうと、ツライものがあるので、「その場で読む 」ように「場づくり」をした方が良いです。
さぁ、「ツミホロボシ」するのだ!
2日目の今日は、「ツミホロボシ」について語りました。エンジニアで「ツミ」をたくさん持っている方は今すぐ滅ぼして行きましょう。
3日目のポエマーは@boiyaaさんです。
素晴しく美しいコンポーネント! 今度はイベリア半島を疫病から救え! パンデミック:イベリア紹介
本エントリは、2016年度 ボドゲ紹介Advent Calendarの1日目です。
1日目はパンデミックイベリアを紹介したいと思います!
2016年いろいろなボドゲが出てきましたが、今回紹介したいのが、パンデミックシリーズの最新作、パンデミック:イベリアです。「オーディンの祝祭」とか「Via Nebula」 も良かったですが、今年はパンデミック:イベリアを紹介したいと思います。
ちなみに僕は、パンデミックシリーズが大好きで、全部購入しています。その中でも、今回のパンデミック:イベリアがいちばん好きかもしれません。それぐらい、良かったです。
さて、紹介して行きましょう。
基本的な説明
パンデミックは協力型のゲームで、プレイヤーは蔓延する病原体に立ち向かいます。パンデミック:イベリアは、パンデミックシリーズの中でも、19世紀の中盤のイベリア半島を舞台に、各地で蔓延する疫病を研究し、蔓延を防ぎます。
では、簡単にその魅力を紹介していきましょう。
非常に美しいコンポーネント
パンデミック:イベリアの魅力はなんと言ってもコンポーネントがとにかく美しいってことだ。箱から空けて中身を見たときは「おお~」となったものだ。
まず箱。美しい。箱の底の模様も良い感じ。
次にゲームボード。イベリア半島。19世紀感があっていいね。
僕が特に「ええなぁ~」と思ったのはカード類。裏の柄がマジでいい。
ひたすら良い。
線路を引くぞ! 浄化するぞ!
ゲームの進め方などは通常のパンデミックと同じように進みます。しかし大きく違うところは、まず線路が引けるということと、水の浄化があるということです。
19世紀中盤ということなので、飛行機なんてありません! 通常のパンデミックはその移動手段として飛行機を使った移動が多いのですが、その代わりの移動手段として、線路を引き移動することができます。線路は1アクション使って建設しますが、線路で繋がっているところであればどこでも1アクションで移動することができます。
次に水の浄化ですが、浄化トークンを置くいて、都市に疫病の感染を打ちけすことができます。このゲーム、通常のパンデミックと違い、治療薬の完成はしません。「疫病の蔓延を防ぐ研究」をすることが目的です。治療薬は完成しないので、研究が進んでも、病原体の根絶や、治療で全部コマを取り除くみたいなことはできません。その変わり、浄化を上手く使って、感染を遅らせましょうということでしょう。
他にも違いはありますが、なかなか通常のパンデミックとは異なるゲーム感が味わえます。線路を引いて、マップが発展するのを見るとなかなか面白いですし、水の浄化を都市にばらまくのも楽しさがあります。また、この違いが、通常のパンデミックの考え方とはちょっと違う脳味噌を使う感じが良いですね。
難易度など
最後に難易度に関しては、協力ゲーの中では比較的易しい方じゃないかと思います。通常のパンデミックより難しいとう声が多いようですが、僕はあまりそうも感じません。むしろ場合によっては、パンデミック:イベリアの方が簡単かなとも思います。
とにかく美しくて、時代の雰囲気が良いながら、病原体を対処しつつ研究しなければならないという焦燥感を感じながらプレイできるのですごく良いと思いました。
明日はさんですakuraruさんです。てかもう書いてた
