fsモジュールでwriteFile()の第三引数やcreateWriteStream()の第二引数ではオプションを渡せる。エンコーディングはそのまま渡すことが多いので、主にパーミッション操作で使うが、書き込みオプションもここで指定する。しかしあろうことか、writeFile()ではflagで、createWriteStream()ではflagsと、違う名前のキーで指定されることを知ってびっくりした。あまり使ったことがなかったので知らなかった。 まんまと間違えたので、上書きされないようにwx+を指定していたつもりが普通に上書きされていた。ひとつ前の記事でやらかした。 修正自体はビルドしなおしで済んだ。しかし同時に行っていたGit for Windows v2.16.1.windows.2への更新で、うまくgit pushができない状態になったりしてハマりかけた。

今のところPromise.all()はそのまま書かざるをえないので、どうせなら全部Promiseの方が統一感あり、パッと見た時に気持ち良い、と感じる。しかし実際に全部そう書くのはとても面倒くさい。そうなると「シンタックスシュガーをください！」となり、キリがない。 当然覚えられないので勘弁してください……となってしまう。本当に勘弁してほしいのは、「そんなに新機能にやっきになるより足元を固めよう」というような論旨のすり替えをしてしまいそうなことだ。 それはそうと並列に外部プログラムを叩きたいというような時、Promise.all()でも並列実行数に制限をかけたい。3か月くらい考えているような気がするけれど、うまくコードに落とし込めない。だいたい途中でその外部プログラムの代わりになるコードをねつ造し、何とかごまかしている。

ある要素にカスタム・プロパティーを使って背景色を指定したとする。そしてその要素に擬似要素を追加する。その擬似要素で背景色を指定すると、要素の背景色が初期化されてしまう。というバグがEdge 15にあった。 View Demo: Background Color Disappearance on Edge 15 デモは変数を定義し、参照するだけの簡単なCSSだ。しかしEdge 15でおかしくなる。Chrome 58やFirefox 53、Mobile Safari 10.3.2、そしてChrome 61やFirefox 55では問題ない。 カスタム・プロパティーの定義済み変数が参照できず、不明な値として初期値が採用されているように見える。擬似要素が追加されることで変数のスコープが壊れているような印象だ。 報告はした……。Edge 15でカスタム・プロパティーのバグがひと通り直るまでは長そうだ

オブジェクトの配列を、各オブジェクトが文字列で持っている日付けでソートしようとし、Date.parse()を使って実装した。しかしもしかするとnew Date().getTime()の方が速いのではないかと調べていたら色々あった。結論としては今はDate.parse()がだいたい速いようだ。 以下は確認に使ったコードと実行結果だ。ランダムな日付けじゃないと正確な答えは出ないかと思ったがそうでもなかったので、この最初に書いたもので計った。 "use strict"; var i; var dt = "2016-04-28T19:15:27+09:00"; var parse = "Date.parse(d)"; var gettime = "new Date(d).getTime()"; console.time(parse); for (i = 0; i < 100000; i++) {

npmコマンドでよく書くパターンにGitで固定のファイルをステージしてコミットするというようなものがある。なんらかの処理を行うメインコマンドのpostコマンドでよくやる。まれにその固定のファイルが更新されないこともあり、その時コミットしてしまうとcommitサブコマンドが正常に(終了コード0で)終了しない。これを避けるためにはステージされることで更新があったかどうかをチェックする必要があることになる。それはdiffサブコマンドの--exit-codeオプションを使うとうまく書くことができる。 例えば更新されているかもしれないfooというファイルをステージして、更新があった場合にのみコミットしたい、とすると以下のようにコマンドをつなげれば良い。 $ git add foo && git diff --cached --exit-code --quiet || git commit --mes

ESLintのルールが教えてもらえないという制限下で作業をしていた。pushすると怒られるという緊張感はちょっと良かった。色々なルールで怒られたが、中でもno-magic-numbersにとりわけ怒られた。怒られたコードをメモしておく。 var d = new Date(); var m = d.getMonth() + 1; 月を数字で取得しようとすると怒られる。 var a = ["foo", "bar", "baz", "qux"]; var firstElement = a[0]; var lastElement = a[a.length - 1]; 最初と最後の要素を参照しようとすると怒られる。Array#shift()やArray#pop()で済むものは置き換えても良いが、若干コストがかかりそうだ。 var s = "foobarbazqux"; if (s.indexOf("

A plea to use semicolons when writing JavaScriptという記事を読んでいた。僕はもちろん書く派だ。なのでこの記事には大賛成……と思いきや、こういった言語的な側面からセミコロンを使うべきだという書き方には賛成できない。これではそのまま逆にすれば使わない理由になりうる。 僕がセミコロンを書くことにしているのは、どこでセミコロンを省略できるのかについて広範で確実な知識を持っていないからだ。むしろ人々がなぜそんなに自信満々に省略できるのかが理解できない。もちろんJavaScript界のとても優れた開発者たちの少なくない何人かがセミコロンを書かない派なのは知っているが、それを真似したところで優れた開発者になれるわけでもない。彼らは優れた開発者でJavaScriptのことを良く知っているからこそセミコロンを省略することができるのだ。 このことはセミコロンを書

日本語の文章では任意の位置で改行できるため、レスポンシブ・ウェブ・デザインでは多くの場合、望まない位置での改行が起きる。例えば最後の1文字だけ次の行になってしまうと、読みやすさや理解度に致命的な影響を与える。例えば「？」だけ次の行に送られた場合、あるとないのでは大きく印象が変わるだろう。Twitterで@Takazudoと@oosugi20の会話を見て、やはりみな似たようなことは考えるものだと感じ、このあたりのことについて書いてみたくなった。 僕はjQueryで最後の五文字では改行が起きないようにいじったりしていた(うろ覚えで書いたもので、実際にはもっと複雑にやっていたと思う)。見出しがテキストのみの場合、最後の数文字の間に非改行ゼロ幅スペース(U+FEFF)を仕込むことで、その間で改行が起こらなくなるという仕組みだ。ここでは比較のためにクラスで判定するように書いてあるが、実際にはh1から