next.jsとnuxt.jsとAngular Universalを触ってみた
server side rendering(ssr)を試したかったので、ssrを比較的簡易に実行できると思われるUniversal Javascriptに対応しているライブラリを簡単に比較してみた。
実行環境
- MacBook Air (13-inch, Mid 2012)
- node v7.9.0
- Typescript 2.2.0
next.js
React用のUniversal Javascriptライブラリ。ここでは、https://github.com/zeit/next.js/tree/master/examples/hello-world を試す。
git clone https://github.com/zeit/next.js.git cd next.js/examples/hello-world/ npm install ./node_modules/next/dist/bin/next build ./node_modules/next/dist/bin/next start
ファイル
index.js
import Link from 'next/link' export default () => ( <div>Hello World. <Link href='/about'><a>About</a></Link></div> )
about.js
export default () => ( <div>About us</div> )
転送量
251KB
nuxt.js
Vue用のUniversal Javascriptライブラリ。ここでは、 https://github.com/nuxt/nuxt.js/tree/master/examples/hello-world を試す。
git clone https://github.com/nuxt/nuxt.js cd nuxt.js/examples/hello-world npm install node_modules/nuxt/bin/nuxt build node_modules/nuxt/bin/nuxt start
ファイル
index.vue
<template> <div> <h1>Welcome!</h1> <nuxt-link to="/about">About page</nuxt-link> </div> </template>
about.vue
<template> <div> <p>Hi from {{ name }}</p> <nuxt-link to="/">Home page</nuxt-link> </div> </template> <script> export default { asyncData ({ req }) { return { name: req ? 'server' : 'client' } } } </script>
転送量
56.1KB
Angular Universal
Angular用のUniversal Javascriptライブラリ。まだ公式にangular-cliとAngular Universalが対応していないようなので、ここでは、 universal-cliを用いてサンプルアプリを作成する。
npm install -g universal-cli rxjs ung new angular-universal cd angular-universal ung build --prod ung serve --prod
ファイル
(ungコマンドによる自動生成ファイル。下記以外も多数生成される)
app.component.html
<h1> {{title}} </h1>
app.component.ts
import { Component } from '@angular/core'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.css'] }) export class AppComponent { title = 'app works!'; }
転送量
215KB (jsはgzip済)
印象
nuxt.jsのファイルサイズの小ささが素晴らしい(ただし、謎に読み込んでいるindex付きのbundleが何をしているか不明なので後で調べたい)。いずれのライブラリも、ssrを意識しなくても普通にレンダリングまで可能なのが凄い。例えばnuxt.jsはexpressに依存しているけれど、hello worldのみだと一行もサーバサイド専用のコードが存在しない。(nuxt-linkというvue-routerに類似したタグが使われているが、これでサーバ側でのルーティングとクライアント側でのルーティングを一元管理しているようだ)。
時間があったらredux or vuex周りとの連携も試したい。
ubuntu16.04(xenial)にelixirをインストール
公式ドキュメントを参照すれば良い。 http://elixir-lang.org/install.html
Erlang & Elixirをインストール
wget https://packages.erlang-solutions.com/erlang-solutions_1.0_all.deb && sudo dpkg -i erlang-solutions_1.0_all.deb sudo apt-get update sudo apt-get install esl-erlang sudo apt-get install elixir
hello world
iex >> IO.puts("hello world")
hello worldできた。
Typescriptでサーバサイドとフロントをどっちも書いてる時にいらいらする点
今、サーバ→node & Typescript, フロント→Angular & Typescriptみたいな構成でコードを書いているのだけれど、
Typescriptのコンパイル結果をサーバ側をES6, フロントをES5で吐かせているせいでその差でいらつくことが多い。
主にfind
。 サーバ側ではhoge.find(y => y.id === 1)
みたいなかんじで一意な値を取ってきてるのだけれど、findはES5では使えないので、hoge.map(y => y.id).indexOf(1)
みたいにしてインデックス取るか、hoge.filter(y => y.id === 1)[0]
みたいに書いている。インデックスアクセス歯がゆい。値がほしいだけなのにその過程で-1とか配列長さチェックとかするのも辛い。幸せをください。
(多段コンパイルでTypescript → Babelが正解なのか...?)
なぜシン・ゴジラはナックルウォークを経ずして二足歩行を獲得することができたのか
(この記事は明確にシン・ゴジラのネタバレを含みますので、未視聴の方は閲覧しないでください)
はじめに
現生生物で二足歩行を行う生き物といえば、真っ先に鳥類が思い浮かぶが、その二足歩行の起源については恐竜にまで遡る。鳥類の起源は恐竜の中でも、多くの種が二足歩行をしていたとされる竜盤目獣脚類とされているからだ(これはティラノサウルスを含む群になる)。そして、彼らがどのようにして二足歩行を獲得したかについては、どうやら以下の論文に目を通したかぎりははっきりとした定説はなさそうだ。
https://www.dinosaur.pref.fukui.jp/archive/memoir/memoir010-055.pdf (恐竜の共通祖先は二足歩行だと思われていたが、実は四足歩行なのではないかという議論がされている)
さて、公開中の映画シン・ゴジラでは、獣脚類によく似た見た目のゴジラが、作中で二足歩行を獲得した。この二足歩行に至る描写がとてもすんなりと頭に入ってきたので、非常に感動した(もしかしたら元ネタがあるのかもしれないけれど)。つまり要約すると、ゴジラは前足が退化していたため、四足歩行することができず、地上では二足歩行せざるを得なかったのだ。
問題意識
まず、そもそもなぜこんな疑問が生じるかについて理解できない方もいるかと思われるので、問題を共有したい。例としてヒトを挙げる。問題は、「ヒトはどうやって(直立)二足歩行を獲得したのか」。その答えは、とてもざっくりと進化論を援用して言うと、「二足歩行可能な形質をもった個体がたまたま発生し、それがたまたまその環境で生き残ったから」となる。しかし、果たして四足歩行しているサルからいきなり二足歩行する生物が生まれるのだろうか。だとしたらなぜ二足歩行の哺乳類は珍しいのだろうか。そのような疑問に答える一つの方向性として、それらの進化の隔たりを埋める中間的な形質を持つ種が存在した、と仮定することができる。それは上記の文脈で言うと、ゴリラ等が行うナックルウォーク(拳をついて歩くこと)、ということになる。樹上生活を行っていたサルが、前足を枝を握るために用いるようになる。前足の形状は歩行には適さない。その中で地上に降りたもの(ゴリラ)が、前足を握り歩行するようになる。しかしそのナックルウォークだとあまりにも移動コストが高い。そのために、森が失われ歩行が優位になる環境では、直立二足歩行というナックルウォークに比べると移動コストの低い手段を用いることのできる生物が、新たな種として固定される。...果たしてこれが明快なストーリーだろうか? 二足歩行なんて不安定な移動法を取るくらいならナックルウォークのほうがましではないのか?(少し古い記事だが、http://sicambre.at.webry.info/200710/article_17.html ナックルウォークは直立二足歩行より後という内容もある)
https://www.youtube.com/watch?v=rVlhMGQgDkY
(近年見られる四足歩行から二足歩行への進化の例)
以上のように、二足歩行について少し考えるだけで頭が混乱してくるのだが、シン・ゴジラの中では二足歩行の獲得は明快に示される。なにしろ、視聴者の目の前で得体のしれない生き物がどんどん進化していくのだ。そして、地上にでてきたそれは当初、前足はひれ状になっており、後ろ足だけが発達している。移動方法は匍匐だ。そして物語は進み、ついに、その両足で立ち上がる。あのやたらと気持ち悪い謎の生物がやっと二足歩行を獲得したのだ。
ゴジラにおける二足歩行の獲得
ゴジラは二足歩行を獲得する順序において、匍匐→四足歩行→二足歩行という脊椎動物の王道を無視し、ひとつ飛ばしに匍匐→二足歩行という進化を遂げた。こここでの進化は、「すでに退化してしまった前足を歩行用に用いる」というオプションではなく、「すでに発達している後ろ足のみでの歩行」というオプションが用いられている。おかげで、匍匐から二足歩行への中間的な形質である四足歩行(ヒトの説明で言えばナックルウォーク)をスキップしている。これは明らかに、前足が退化していたおかげである。これは二足歩行を獲得する上で非常にスマートな回答のひとつだと自分は思う。シン・ゴジラ公開前に、自分は「このゴジラ前足がちっちゃい!前足がちっちゃい!」としか思っていなかったが、その伏線が回収された瞬間が、このゴジラ立ち上がりシーンだと言える。オットセイ、アシナシイモリ、ヘビ類等に準じた退化をし(有尾類のネオテニーが可能性が高いと睨んでいるが)、十分な歩行器官の無い生物だからこその、二足歩行の獲得。それを視聴者の前でやってのける映画力、さすがだ。この映画の95%ぐらいの面白さはここに詰まっている。
最後に
この記事はゴジラが四足歩行を獲得した生物(両生類や爬虫類)から進化した、という仮定にもとづき書かれているが、「単に魚から進化しただけでは?」というつっこみにはじまり、生物学的に不適切であることが確実なため(用語も適当、"中間的な形質"、とか、進化論ではなんていうんだろう?)、不備については順次指摘されたい。また、「どうしておばあちゃんのお口はそんなに大きいの?」「それはお前を食べるためだよ」的な考察(たぶんビルで視界が塞がれるから立ち上がったんだと思うが)もしていないので、そちらについても気になっていることではある。ゴジラの二足歩行に対して専門的な意見を持っている方がもしおられれば、随時ネット上に関連記事をアップしていただけると非常にありがたい。
zsh + pretzoでdocker-composeの補完
curl -L https://raw.githubusercontent.com/docker/compose/$(docker-compose version --short)/contrib/completion/zsh/_docker-compose > ~/.zprezto/modules/completion/external/src/_docker-compose
以上です。
Erlangでリスト操作(map, filter, foldl等)
今、時間があるときにErlangを触っているのだけれど、関数型デザインの言語だけあってリスト操作の関数が充実している。そこで、Erlangのリスト操作関数の内、よく使いそうなものを以下にリストアップしてみた。
map
リストの各値に関数を適用した新しいリストを返す。
map_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], AddOne = fun(X) -> X + 1 end, lists:map(AddOne, L1).
filter
リストの各値をフィルターしたリストを返す。
filter_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], IsEven = fun(X) -> X rem 2 == 0 end, lists:filter(IsEven, L1).
fold
リストの各値を畳み込んだ値を返す。リストの左から計算するか右から計算するかによってfoldlとfoldrがある。
fold_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], Add = fun(Acc, X) -> Acc + X end, lists:foldl(Add, 0, L1).
zip
2つのリストを合体させる。下の例だと[{1, 11}, {2, 12}, ...]のようなタプルが入ったリストになる。
zip_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], L2 = lists:map(fun(X) -> X + 10 end, L1), lists:zip(L1, L2).
flatten
ネストされたリストからネストのないリストを作る。
flatten_test() -> L1 = [1, 2, 3, [4, 5, 6], 7, 8, 9, 10], lists:flatten(L1).
flatmap
値からリストを作る関数を受け取り、それを引数のリストの値に対して適用してから、flattenする。下の例だと[1,1,1,2,2,2,...]のように返る。
flatmap_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], lists:flatmap(fun(X) -> [X, X, X] end, L1).
takewhile, drop while
takewhileは比較関数がtrueまでの値の入ったリストを返す。drop whileはその逆。
takewhile_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], IsLess5 = fun(X) -> X < 5 end, lists:takewhile(IsLess5, L1).
dropwhile_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], IsLess5 = fun(X) -> X < 5 end, lists:dropwhile(IsLess5, L1).
partition
比較関数でリストを分割する。
partition_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], IsLess5 = fun(X) -> X < 5 end, lists:partition(IsLess5, L1).
merge
二つのリストをソートして合体させる。merge/3はソートに用いる比較関数を引数に取れる。
merge_test() -> L1 = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10], L2 = lists:map(fun(X) -> X + 10 end, L1), lists:merge(L1, L2).
JSだとunderscoreとかを使わなきゃいけないことも組み込みで入っていて便利。
Ubuntu 16.04でcaps lockをCtrlに変更
どおりに。
- gnome-tweak-toolをインストール
sudo apt-get install gnome-tweak-tool
tweak toolを起動
Typings -> Caps Lock Key behavio -> MakeCaps Lock an additional Ctrl
かんたん。
(ちなみにTyping -> Alt / Win key behavior -> Alt is mapped to Win keysでaltとwinを交換できたりする)
- 出版社/メーカー: 東プレ
- 発売日: 2006/02/25
- メディア: Personal Computers
- 購入: 14人 クリック: 732回
- この商品を含むブログ (61件) を見る