azu

This result is expected. first `"` is missing and sentence-splitter can not parse it correctly. natural language does not have parse error. This makes it difficult to correct implicit errors....

`ECONNRESET` is happened when the request is timeout. The reason come from server side. - [node.js - Node js ECONNRESET - Stack Overflow](https://stackoverflow.com/questions/17245881/node-js-econnreset) 📝 Maybe It is releated Node.js issue...

# 辞書の典型分類 Date: 2017/05/08 ## Status 議論の余地があり ## Context prh.ymlを使った場合の辞書には大体の分類が隠れていると思われる。 幾つかのプロジェクトを調査し、典型的な分類をまとめる。 ## Decision - https://github.com/asciidwango/js-primer/blob/master/prh.yml - ドメイン固有 - typo - 文体 - 漢字の開き - https://github.com/azu/JavaScript-Plugin-Architecture/blob/master/test/prh.yml - ドメイン - typo -...

https://github.com/proofdict/proofdict opinionatedなルールを管理する仕組みを作った。 これをもっと気軽にforkできる形になればいい気がする

辞書管理アプリみたいのがあるとよさそう。 だけどその場合はどこにデータを保存するかという問題が起きそう

proofdictの仕組みを元に、もっと一般ユーザーが使える仕組みを作りたい。 データはGitHubに公開しておくとメリットがある形にすれば、辞書の再利用性が高まる。 GitHubのリポジトリを管理するコストもあるけど、それを超えるメリットを用意すればもっと良くなりそう。 既存の辞書(prh)などの問題点はローカルにコピーして使うため、プロジェクトごとに毎回コピーしたりして面倒臭いところ。個人ごとにテンプレ的な辞書はあると思うので、そこを補える形にしたい。 ## 辞書のフォーマット prhをベースにしたもの。 通常の辞書のように品詞に特別な意味を持たせる。 `noun`ならマッチ規則が変わる。(これを`tags`にするのかは再度検討が必要そう。カテゴリ?) - https://github.com/proofdict/proofdict-tester/blob/41b56eb32caba70b67a61df7966f33563f0a0498/src/TagFilter.ts#L4 `id`は1ファイル=1辞書をしっかりルール化すれば、必須ではなくなるけど自動生成的には合ったほうがよさそう。 ```yaml # `id` is unique string id: 01BQ92YYBEFBXEHH8T8HC8RCRD # `description` is a short comment description: 'Reference https://www.ecma-international.org/publications/standards/Ecma-262.htm' #...

proofdictをリファインしてる

> http://azu.github.io/morpheme-match/?text=%E5%BD%93%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AFGitBook%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%A6%E7%94%9F%E6%88%90%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%82%8B%E3%80%82 > 当ドキュメントはGitBookを利用して生成されている。 上記の文章が常体とも敬体とも認識してないため、エラーがないのは意図通りともいえますが、 どういう状態が意図した挙動でしょうか? ("生成されている"を常体とみなすのかがわからないため、明らかに常体な"である"のみを判定の対象としているため起きている感じです)

文末に "いる。" のパターンがきたら、これは常体だとみなす実装を加えれば判定はできるのですが、 このパターンには一致するけど、常体じゃないようなパターンがないかが懸念事項ですね。 (文脈によって異なるという感じになってくると、今の実装だと正しく判定するのは難しいですね)

このルールを使ってリファクタリングしてみた。 [refactor(textlint): 敬体(ですます調)と常体(である調)の使い分けを厳密に by azu · Pull Request #94 · azu/JavaScript-Plugin-Architecture](https://github.com/azu/JavaScript-Plugin-Architecture/pull/94) ``` diff -先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけであるため、 +先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけで、 それぞれの処理がどのように実装されているかはよく分かりませんでした。 ``` ``` diff -BufferはStringと相互変換が可能であるため、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。 +BufferはStringと相互変換が可能なので、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。 ``` ``` diff -gulpではプラグインが持つ機能は1つ(単機能)であること推奨しています。 +gulpではプラグインが持つ機能は1つ(単機能)とすることを推奨しています。 ``` ``` diff -`jQuery.fn`の実装を見てみると、実態は`jQuery.prototype`であるため実際にprototype拡張していることがわかります。...