npmのoptionalDependenciesの使いどころ
npmのpackage.jsonの依存パッケージの定義には、よく使うdependencies、devDependenciesの他に、optionalDependenciesというのもあります。
今まで存在を知らなかったのですが、「optional」という名のとおり、なくても問題ないとか、特定の環境でだけ必要とかの場合に使うもののようです。
最近JavaScriptのライブラリを作ったのですが、そこで「開発にもライブラリ本体にも必要ないけど、サンプルコードの中で使ったパッケージ」がありました。サンプルコードを正しく動作させるのにはインストールしてほしいけど、なくてもライブラリの動作とか開発には影響はないので、これはまさにoptionalDependenciesではないか、と思って初めて使いました。
ライブラリは(この前も書いたけど)これです:
https://github.com/PrestoTools/presto.js
なかなか使う機会はなさそうですが、optionalDependenciesの一例になるのかな、と思ってメモ。
小さなJSライブラリ作った時に使ったもの
- ピュアなJavaScriptで書いた
- JSのファイル数は10もない
使ったもの
- rollup.js
- Babel
- prettier
- ESLint
- UglifyES
- Jest
あとGitHub -> CircleCIでビルドしてる。ビルドする時にCode Climateにテストスコアを送ってる。
今導入してもいいかも?
- TypeScript・・・もう少し大規模になるなら型があったほうがいいのかも。そうするとBabelは不要になるのかな。
2017年の振り返り
今年は書くぞー。
設計
プログラムの設計とかファイル構成なんかに、だいぶ気を遣うようになった。
一人だと何やっても勝手ではあるけど、やっぱりちゃんと整理しておいたほうが機能追加も仕様変更も対応しやすい(当たり前だ・・・)。
ただ、設計に凝りすぎてなかなか手が動かなかったり、ファイルを分割しすぎて逆に全体が把握できなくなったりもしたので、その辺のさじ加減はもうちょっとうまくできるようになりたい。
たぶん、もうちょっとゆるく書き始めて、複雑になってきたら分割すれば良いんじゃないか、と思う。
React
WebアプリケーションのフロントはほぼReactで書くようになった。
簡単なものだったらReact+Fluxで、複雑になってきたらRedux、XHRが入るならredux-thunk、で4〜5つ作ったor作りかけている。
たぶん、Component志向でVirtualDOMならReactでなくてもいいんだとは思うけど、慣れてしまったので、しばらくはこれでいいかなーという心境。
あとは以前にBackbone.jsをカオスにして作ったけっこう大規模なアプリケーションを書き直したい・・・。
Vue.jsとAngular2
も、ちょっと触りました。
先にReact触った人間なので、Vue.jsのほうがとっつきやすかった。
ただ、昼間に大学でReactを書き、夜に自宅(フリーランス)でVueを書く、という事態に陥った時期があり、両者の記法が混同してものすごく効率が悪かった・・・。
CSS
BEMにECSSをちょっと足した、みたいな独自の設計方針で落ち着いてました。
で、Webアプリでどうせbuildする場合はSASSで書く感じ。
CSSの仕様はひととおり把握できてきたようで、「なんでこういう表示になる(ならない)の?」と思うことはなくなった。なんか一定の段階には達した気がする。
サーバサイド
RESTfulAPIをフロントと同じだけ作ってるけど、RubyだったりPHPだったりNode.jsだったり。
内容にもよるけど、どれも一長一短な気がして定まっていないので、来年はなんとかしたい。
その他
nginxの設定とか、Neo4jとかSPARQLとか。あとPythonが少し。
旅行記
いろんなとこに行きました(@出張)
大阪
京都・・・写真がない
盛岡・・・写真がこれしかない
ダブリン
からの、ロンドン
東京が何度か・・・わざわざ写真撮ってない
熊本
来年もどこか行けますかね。
仕事とはいえ好きにさせてもらって、家族には感謝してます。
named pipeでオンデマンド・ダウンロード
「オンデマンド・ダウンロード」って勝手に呼んでるんですけど、要するに、ダウンロード要求があった時に、サーバーサイドで動的に(複数ファイルから)tarを生成してダウンロードさせる、というのを実装した時のメモです。
サーバにダウンロード対象のファイルが数万あって、どのセットをダウンロードしたいかが動的に決まるので、予めzipなどを用意することができない、でもファイル1つずつダウンロードしてもらうのは面倒、という状況でした。
デメリットとしては、tarなので圧縮されない、というのはあります。(今回の状況では、対象のファイルはバイナリが主で、大幅な圧縮は期待できないのでそれでも構わないとしました。)
実装にはnamed pipeを使いました。
named pipeとは:
名前付きパイプ - Wikipedia
これを使えば、一旦ファイルに書き出さなくても、プロセス間で通信(データの受け渡し)ができます。今回はtarの中身をパイプに流して、Webサーバのレスポンスとして使います。
named pipeを作って、tarを流す。
$ mkfifo pipe_path $ tar cvfh pipe_path tar_path
pipeに流れているものをPHPからレスポンス。
if (file_exists($pipe_path)) { header('Content-Description: File Transfer'); header('Content-Type: application/octet-stream'); header('Content-Disposition: attachment; filename="tar_name.tar"'); header('Content-Transfer-Encoding: binary'); header('Expires: 0'); header('Cache-Control: must-revalidate'); header('Pragma: public'); header('Connection: close'); ob_end_clean(); readfile($pipe_path); exit(); }
最終的なファイルサイズが決まらないため、ブラウザではダウンロードの残り時間の予測は表示されません。
また、環境によるかもしれませんが、上記のような感じで、
1. PHPからnamed pipeを作るシェルスクリプトを実行
2. ダウンロード(レスポンス)開始
とやる場合、1と2の間で1秒くらいsleep()を入れるとスムーズでした。そうでないと、file_exists($pipe_path)でfalseが返ってくる場合がありました。
NDS第52回勉強会に行ってきたよ
51回に引き続き、第52回勉強会(2017/06/17) - 長岡 IT開発者 勉強会(NDS)に行ってきました。
前回も書きましたが、NDSは名称に「IT開発者」とあるとおり、幅広い分野の開発者さんが参加しているところが好きです。
私は今回はCSSのお話をさせてもらいました。
今日から使えるCSSパターン // Speaker Deck
自分自身がCSSのコーディング業務で取り入れてよかったもの、みたいな切り口で、短め(10分)の発表にしました。
もうちょっときちんとした設計論みたいなものに昇華できたかな、という気もしますが、そういったものはすでに世の中に出てますし、勉強会のテーマも「初心者むけ」だったので、と言い訳しておきます。
その次元に持ち上げる論理的回路が私の頭にはないみたいです・・・。
ひとつだけ補足で、ECSSという手法に触れていますが、
日本語記事ではこちらのシリーズがとても分かりやすいです。
連載 | Enduring CSS | HTML5Experts.jp
以下、みなさんの発表を聞きながらのメモ・感想など:
「はじめてのC#プログラミング」ailightさん
「C#」にとどまらず、アセンブリあたりからの流れをお話ししてくださっておもしろかったです。
実際にコードを見せてもらうと、やったことない言語でも少し触ってみたら学びがありそうだな、と思いました。
「うまく書きたいと願わないと書いてもうまくならない」「プログラムを書かなければバグは出ない」はまさに真理だと思います!
「なんてかんたんなJavaEE」civicさん
JavaEEには馴染みがなく、どんなものか知らなかったのですが、
JSONを返すREST APIを作るデモを見せていただいて、概要をつかむことができました。
以前にJavaでWebアプリケーションを開発している人とお話したことがあって、
(類似のサービスを私が作っていたため、どんな仕組みか説明してくれた)
あれはきっとこういうフレームワークを使っていたのだ、と悟りました。
「文字コードとプログラミング(仮)」gonchan93さん
文字コードは深く考えると大変そうで、いつもなんとなくUTF-8でやっていましたが、
どうやらそれで大丈夫だということと、
今はメールもUTF-8でOK、という学び!
データベースが絡む場合など、みなさん苦労してるんだな、ということが分かったのも良かったです。
「Ncatを使おう」hayajoさん
Ncatって何だろう、と思っていたら、コマンドでした。
HTTPクライアントにもサーバにもなってくれる、とても便利そうなものでした。
HTTP->HTTPSの変換ができるとか、さっそく開発に活かせそうな感じがしました。
とりあえずHTTP/2通信できるかやってみたいです。
「怖くないし役に立つ設計原則の話」neko_gata_sさん
実際にプログラムを組むにあたって、どのように設計原則を活かすのか、というお話でした(と理解しました)。
自分自身を「設計」を考えるのがわりと好きなタイプだと思っているので、とても興味深かったです。
DRYでないコードが出てきたときには、共通化のほかに分割し直す、というアプローチを考慮すべきということ、と、
将来的に変わるかもしれない仕様と、変わりにくい仕様、という視点があるということ、の2つが大きな学びでした。
※私の発表の背景にあった設計についての概念に似た部分があって、自分の発表の前にこのお話があったことで、意図せずフォローしてもらった感じがします。大変助かりました!
「はじめてのソフトウェアテスト」kasacchifulさん
テストについて、種類や原則、手法まで取り上げられていて、「テスト」というのは自分が漠然と思っていたよりも広い世界なんだな、という印象を受けました。
<自分的メモ>
ドキュメントの段階で欠陥がある場合
費用や時間との兼ね合い
3色ボールペン
テストの設計・実施をそれぞれどのタイミングで行うか
「はじめての修羅場」hiro_ishibashiさん
タイトルのインパクトが強大ですが、内容はとても冷静に分析されているものでした。
こんなPMさんが修羅場に降りてきたら間違いなく救世主に見えます。
「新人研修の作り方」のその後 LT5min masaru_b_cl
習得速度のばらつきなどを検証して、改善していっているとのこと。
小さなステップに分割する、チュートリアルのコードを拡張してもらう、など。
私の場合、大学でわりとほったらかし気味(?)に教わっただけなので、企業での研修のお話は新鮮でした。