Irina Shestak
interactiveなcommand lineアプリケーション
オプションの意味を全て理解しながらcommand line command を打つのは難しいよね
commnadをprogramに伝えるという表現ではなく、プログラムと対話すると表現するべきじゃない？ webpageだと登録とかインタラクティブにできるとわかりやすいし、コマンドラインもそうあるべきじゃないか
より使いやすくするための対話性をレクチャーします
bash,ruby,perlなど色々あるけど、nodeを使うのがベストでしょう
-
lv1. argument parsing yargsというargumenr parserがすごい使いやすい
-
lv2. give your options aliases 多くのoptionは大体aliasを持っている
--name = -n など
-
lv3. set up default values
-
lv4. provide a help menu yargs使うとhelp function呼び出すだけで簡単にできるよ
必須ではないオプションなどわかりやすい表示がなされる
- lv5. get input from your users interactiveにinputを受け取るためにはpromptで受け取れる prompt.start()
yargsじゃなくてpromzardというのもあるよ
- lv6. why not use commands オプションを沢山与えると複雑になるから、インタラクティブなほうがいいよ
コマンドの外部ファイル化もできる
Thomas Watson
http://togetter.com/li/1047941?utm_source=dlvr.it&utm_medium=twitter
opbeatというパフォーマンスモニタリングをする会社 Node.jsがたまにパフォーマンス低下するからそれをモニタリングするのが仕事
どうやってproductionのデバッグをするか
why is it important ? なぜproductionになるとパフォーマンス issueが発生するか
remoteで発生するissueをdebugするのは難しいから
live applicationのPerformanceに影響を与えたくないのでremoteでdebugするのは難しい productionのapplicationはどうやってフックしようか
premature optimization
baseline performance
measuring どうやってperformanceを解析できるか
JSONでかかったらparseに時間かかるよね
JSON.parse(req.body)
->
console.time('json-parse')
JSON.parse(req.body)
console.timeEnd('json-parse')
// json-arse 131ms
Causes of Slowness
-
single-threaded 必ずしも理由というわけではないけど、ひとつの要因
-
cpu intensive code
-
slow I/O databaseのi/oとかとか
-
event loop saturation Node.jsのevent loopがいっぱいになる たくさんcallbackよんだり
-
running out of memory メモリたんなくなったり
-
garbage collection Node.jsのGCの実装は,GCが起きると全てのengineのプロセスが止まるので自分のアプリケーションが動かなくなる
- syncronous i/o
- json.parse
- momeれず...
nodejs --perf_basic_prof_only_functions cpu.js
このオプションはproductionでも実行できるからモニタリングできるひとつの方法 node > v6以上でperfログというのがとれるようになる linuxのperfログから出力できる
perfというツールを使ってみる 実行してるサーバをperfというツールで監視して別タブでアクセスを大量に送る
perfは動いているサーバのモニタリングをする 解析はperf.dataというファイルから読み解く /tmp以下にperf-2466.mapのようなファイルが出来る
nodeサーバがなんのlinuxカーネルを呼び出しているかの解析ができる
https://www.npmjs.com/package/0x https://github.com/brendangregg/FlameGraph
solaris mdb v8のcoredumpできる
autopsyというツールがあるよ
Barak Chamo
Richard Littauer
README is 最高. README is super important.
ドキュメンテーションの最初のcontact documentationよりREADMEの方が大事
多くのREADMEはinformation的に足りてない
README ARE DIFFICULT
standard is easier standard jsがあると無駄な議論が減って本質的な開発をする時間が増える
what is in standard-readme
- a specification
- a generator
- a linter
- a badge
- example templates
spec overview required
- title
- short description
- ToC(if > 100 lines)
- install
- usage
- contribute
- license
Bradley Farias https://docs.google.com/presentation/d/1J9mN3N1KZXGwn7ufrv9UAIiUzKo8zsQaQwIKseebjzo/edit#slide=id.g18cb3b1c5f_0_263
Node.jsではv8での実装待ち ECMA形式のモジュールが導入されるのは最速でもNode10から
scriptとしてパースするか、モジュールとしてパースするかによって結果が違うかもしれない
.mjsという拡張子でecma moduleと判断するのが有力 複数回 requireされたときどういう挙動になるのか。常に同じものが返らなければいけない。そうすると、GCの対象にできない
babelは人気だけどstandardを守ってない script and module grammerが混ざっている
この辺守ってないのやめてよね
- Non-ESM behavior
** Loading Errors
** Runtime Errors
** Cache
** Named import variables compile to property access
module.exportsis mutable
これはやばい Bluebird.promisifyAll does not work on ESM
babelと互換取らないといけないと思ってる？ -> 個人的には取らなくていいと思ってるけど、全体的には数100あるモジュールを守るためにある程度考えてる
monolithic JavaScript 流石に重すぎるから更新のあった部分だけhashを再生成して分割
- webpack.jsonp
- library
- 各画面ごとのjs
分割しててもエラーが発生したら画面reloadすればSSRでちゃんとエラーを表示してくれる
Partial renderingはSSRとSEOスコアが一緒
SSRは逆に遅くなるからあんまやらないほうがいい
routingやSSR, コード分割,razy loadなどを自動で行う
SPAの問題
- 初期表示がが遅い
- ページが増えると重くなる
SSR 初期表示パフォーマンスの工場、SEO -> jsファイルを置くだけにする(Next.js)
「リッチなWebアプリケーションのための7つの原則」読んでね
css glamorライブラリを使う vendor prefixとかもやってくれる
Linkコンポーネント pushStateを使ったページ遷移を提供する
isomorphic
- nowをインストール
- nowコマンドを実行
- 初回のみメールによるログイン
npm install -g now
now
イミュータブルデプロイ デプロイするごとに新しいURLが作成される 古いURLは消す必要はない
公開するためにはわかりやすいエイリアスを生成されたリンクに貼る
メリット
- URLに対する一意性がある
- デプロイ作業が簡単 ** デプロイしたものがokだったらエイリアスを張り替えるだけでデプロイ完了
docker fileも対応してるよ
reworkでautoprefixer作ってたけど、作者(TJ)にdisられたし自分で作ってみたぜ -> PostCSS
compassに比べてautoprefixerが約50倍高速
stylelint
stylefmt -> 自動フォーマットしてくれるツール
postcssのpluginはここで探してね http://postcss.parts/