はてなブックマーク

自作 npm xlsx-extractor を JavaScript から TypeScript へ移行した際の覚書。はじめて npm 開発した時の npm icon-gen v1.0.0 release を踏まえて、新規 npm を TypeScript で実装する場合の入門記事として機能することを考慮しながら書く。 パッケージ仕様と開発方針 開発対象となる xlsx-extractor の仕様と開発方針をまとめる。 仕様 Excel ファイル (*.xlsx 形式) を解析してシート情報とセルを取得する 空のセルは詰めずに最大の列と行で埋める Excel 上のセル座標を維持する 例えば B7 に値がある場合、0 開始の座標で B = 1 7 = 6 として常に [1][6] で取得可能とする インターフェースは Node.js 用と CLI の 2 種類へ対応 CLI は標準出力にシー

ブログを WordPress + さくらのVPS から GatsbyJS + Netlify へ移行した。その作業メモをまとめる。 移行補助ツール WordPress から GatsbyJS へ移行する際に使用した補助ツールについて。 wpxml2md WordPress の記事を GatsbyJS 用に Markdown 化するためのツール。 wpxml2md - npm WordPress の Markdown 移行補助ツールを開発してみた これは WordPress の管理画面から出力した XML を解析して、記事単位の Markdown ファイルに変換するというもの。当初は変換ぐらいしか実装していなかったが、移行にともない機能不足を感じたので以下を追加した。 メタデータ埋め込み 記事 XML からタイトルや日付を解析 記事ファイル冒頭へ gatsby-transformer-rem

本記事は Redmine Advent Calendar 2018 の 17 日目です。Redmine テーマ開発について書きます。 Redmine テーマとは？ Redmine を機能拡張する方法としてプラグインとテーマが提供されている。 プラグインは Redmine の API や DB を直に参照・操作可能なので高度な用途に向く。テーマは CSS と画像、JavaScript など Web フロントエンド技術のみで開発され、外観の変更や Web ブラウザーで可能な範囲の簡単なカスタマイズを担当する。 プラグインは高度な機能拡張を可能とする反面、開発の難易度も高い。バグや Redmine 本体との互換問題が起きるとシステムそのものが動作しなくなる危険性もある。そのため上級者向きといえよう。エンド ユーザーとして利用するにしても慎重な管理を要求される。 テーマの機能は Web ブラウザー

Node 11 へ更新したら mapbox/node-sqlite3 が動作しなくなった。#1063 によれば既に修正の準備はできているものの CI サービス AppVeyor が Node 11 対応していないので待ちとなっているらしい。 これまでも node-sqlite3 のように node-gyp を利用した npm で Node バージョン更新による問題に遭遇してきたが、概ね短期間で対応された。そのため Homebrew で Node を最新バージョンにしていたのだけど、今回は 2 週間を経ても未解決である。ちょうど直近で node-sqlite3 を業務利用する機会があるため、これは困る。 また自身も npm 開発することもあって、いつかは *env 系ツールで複数 Node バージョンを検証できなくてはなぁと思っていた。Current 以外の動作テストは Travis CI

最近 React SFC (Stateless Functional Components) や Redux の影響を受けて、ES.next な環境でもクラスより関数で実装するようにしている。ES Modules であれ Node であれ個別に関数を外部公開できるからクラスを使用せずとも実装には十分だし、むしろ関数を積極的に採用することで外部依存を引数に限定できる。 しかし困ったことが。非公開の関数を単体テストする手段がない。 そもそも非公開なものをテスト対象とするのは悪手では？と言われればそのとおり。しかし公開関数が単一単純でも内部で多くの非公開な関数へ依存しているなら、それらを個別に単体テストしたくなるだろう。外部からみたら公開関数を単体テストしているつもりでも実際には結合テストなわけで。 クラスなら今のところアクセス指定子がないため、非公開メソッドは命名を工夫する慣習 (アンダースコ

2018/5/26 (土) に redmine.tokyo 14 へ参加 & 登壇。以下、レポっす。 第14回勉強会 - redmine.tokyo 2018/5/26 第14回勉強会 - redmine.tokyo #redmineT - Togetter 開場前 最寄りは都営浅草線の泉岳寺駅だが、自宅からのルートだと乗り換えが面倒なので京浜東北線の田町駅へ 田町駅で昼食、「いろり庵きらく」の「板そば」を頼んだらボリュームかなり多くて食べきれるか心配だったので飲み込む感じで処理 国際興業三田第 2 ビル、休日なので通用口から入るとのことだが案内してくれる方がいたので迷わず入れた 会場には 12:30 ぐらいに到着、着席 開始までの時間に持参 PC のプロジェクター接続確認してほしいとのこと ここでケーブル忘れに気づく、というか会場にあるのを期待する他力本願メソッドにも程があって、つまりは

業務プロジェクトへ CSS Modules 導入を検討中。しかし JS/CSS ともに大きく設計変更されるため、いきなり採用するのは怖い。というわけで、そこそこの規模と複雑さを持つ examples-electron/audio-player で試してみた。このプロジェクトは Electron 製の簡易音楽プレーヤーになる。JS/CSS まわりはこんな感じ。 JavaScript AltJS は Babel と babel-preset-env、ES.next 範疇の機能と構文のみ使用、ターゲット設定は electron なので少し古い Chorome 相当になる View は React Flux は material-flux、いずれ redux か mobx あたりへ乗り換える予定 Bundler は webpack Electron の Main/Renderer プロセスともに

年末に PostCSS + cssnext と CSS Modules を試したのだが、コメ欄の指摘とそれを受けた追記を読んでもらえるとわかるとおり次世代 CSS 仕様の先取り = CSS.next のつもりで導入した cssnext が微妙だと感じはじめている。 cssnextを使うべきか - yuhei blog QiitaのCSS構成2017 - Qiita これらの記事でも言及しているとおり cssnext の採用する PostCSS プラグイン は CSS Working Group の認知していなかったり取り下げられそうなものもある。前者は直せばよいけど後者については直近の仕様だと冗長な記述が避けられないことを意味している。私は少なくとも モジュール管理 @import が URL ではなくモジュール参照として解決される 変数 (定数) と Mix-In 色やサイズなどを変数

このあいだ書いた記事の締めで予告したとおり Stylus からの移行先として PostCSS + cssnext を試す。 サンプル プロジェクト : examples-web-app/postcss 2017/12/29 追記 : cssnext は CSS.next と呼べるか？ 本記事のコメント欄にて @mysticateaさん から指摘され、cssnext の機能すべてを CSS.next と呼ぶのは妥当ではないと判断した。 w3c/csswg-drafts: CSS Working Group Editor Drafts [css-nesting] Status? · Issue #998 · w3c/csswg-drafts 私が CSS.next だと思っていた CSS Nesting Module は CSS Working Group (以下、csswg) の draft

これまで Web フロントエンドや Electron の JavaScript ビルドには Browserify と Babel を使用してきた。しかし Browserify の開発は停滞している。現在は個人から org 運営へ移管しており browserify/discuss にて開発者の募集や議論もおこなわれているものの、往時の勢いはない。 私としては CLI のみで完結して設定を package.json に集約しやすい点から Bundler の中では Browserify 推しだった。しかし今後のことを考えると webpack に移行したほうがよいと判断せざるをえない。 というわけで Electron プロジェクトの開発環境に webpack を導入してみた。以下はその覚書。 サンプル プロジェクト akabekobeko/examples-electron Browserify

icon-gen v1.2.0 をリリースした。 Release v1.2.0 今回の目玉は ICNS における is32 と il32 のサポート。Wikipedia の Apple Icon Image format によると ICNS は現行の macOS なら ic07 〜 ic14 があれば十分にみえる。しかし GitHub にて Mac OS X finder uses also is32 and il32 icns. という Pull Request があった。どうやら is32 と il32 も必要とのこと。これらがないと Finder のリスト表示でアイコンが消えるらしい。 この報告をうけて High Sierra 環境でリスト表示を試したものの、正常に表示されていたので古い macOS 固有の問題かもしれない。私の環境だと再現できないため Pull Request をそ

$ npm run app > electron-audio-player@1.4.0 app .../examples-electron/audio-player > electron --inspect=5858 src/ Debugger listening on port 5858. Warning: This is an experimental feature and could change at any time. To start debugging, open the following URL in Chrome: chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:5858/ee7b65f0-dc0d-46f7-9d9e-9974419

Atom v1.19.0 の更新があったので反映したら IME 入力がおかしい。例えば「にほんご」と入力した場合、変換中は一文字目だけしか表示されず順に「に」、「ほ」、「ん」、「ご」と切り替わってゆく。変換前の文字がひとつしか見えないので、まともに入力できない状態。あまりに致命的な問題なので issue があるだろうと探したら以下をみつけた (ついでにコメントしておいた)。 1.19.0-beta2: Cursor stucks at the first letter when using macOS Chinese IME beta2 で見つかっていた問題だけど残念ながら安定版でも再現する。コメントを読むと影響があるようならダウングレードしてほしいとのこと。Atom の標準機能としてはダウングレードを提供していないので手動実行する必要あり。手順は以下。 Atom が起動しているなら終了し

タスク ランナーは npm-scripts 派なのだけど akabekobeko/examples-web-app に公開している front-end-starter には gulp 版も用意してある。かつて gulp を利用していたこと、世間では現在もそれなりに Web フロントエンド開発で gulp が採用されていることから動向チェック用にメンテナンスしている。 front-end-starter は Electron も含む Web フロントエンド開発環境の変更を気が向いたときに反映しているのだが、そういえば uglify-es を gulp で利用したくなったらどうするのだろう？というのが気になったので試してみた。 gulp-uglify gulp で uglify-js を利用する場合は gulp wrapper となる gulp-uglify を採用するのが一般的だろう。では

小ネタ。 Electron が採用している Chromium は ECMAScript 対応がかなり進んだ。よって Babel を使用しつつも変換を最小におさえたくなる。 この点について以前 babel-preset-env と minify という記事を書いたのだが uglify-js の ES2015 以降への対応は暫定版。そのため、よりよい選択肢として babel-preset-babili を試してみた。その記事のコメントで mysticatea さんが提案されているように Browserify へ -g オプションをつければ node_modules 部分も含めて minify 可能だが、それでも Browserify の Bundle 処理は minify されない。 よって uglify-js harmony 版が正式リリースされるのを待っていたところ uglify-es が

以前、npm 開発で脱 Babel してみるという記事を書いた。そして二ヶ月ほど特に問題なく運用できていたのだが、babel-preset-env を試してみたら考えが変わった。 脱 Babel を決めた時点では latest で常時 ES5 変換か plugin を細かく組み合わせることを想定。しかし babel-preset-env なら明示的に Node のバージョンを指定することで必要最小の変換をおこなえる。Node としては ES Modules 以外の ES.next 仕様へ積極対応しているため、Active な LTS を下限としておけば変換は ES Modules + α ぐらいで済む。 というわけで Babel を再導入することにした。 プロジェクト構成 Babel を再導入した akabekobeko/npm-xlsx-extractor の構成例。

ここ数年 Markdown で資料を作成する機会が増えたのでブログもこれで書きたくなった。Markdown なら対応エディタも多くて可搬性が高い。また WordPress から別の CMS へ移行しやすくなるだろう。例えば Hugo のような静的サイト ジェネレーターなど。 このブログではプログラミングについて扱うことが多いので、ソース コードの構文強調も重要である。これまでは機能性から SyntaxHighlighter Evolve を利用していたが、ES2015 や Stylus など最近、登場する機会の増えた言語がサポートされていないので、こちらも乗り換えを検討したい。 Jetpack の Markdown 機能を利用する WordPress を Markdown 対応させるプラグインはいくつかあるが、信頼性とサポートを考慮して Jetpack を採用することにした。 このプラグイ

babel-preset-env と minify の続き。前回は ES.next なコードを minify する方法として uglify-js を中心に babel-preset-babili を少しだけ試したところで終わった。今回は後者の使い方を掘り下げる。 Babel における plugin と preset babel-preset-babili は ES.next な JavaScript を ES5 以降の書式に変換する Babel 関連のツールで minify を担当。 現在の Babel 本体はランタイムに徹し、実際のコード解析や変換はランタイム上で動作する plugin により処理される。開発者は機能ごとに plugin を組み合わせることになるが、これらは膨大である。そのため直に利用せず plugin 集となる preset を選ぶほうがよいだろう。 例えば以下のような

{ "babel": { "presets": [ [ "env", { "targets": { "electron": 1.6 } } ], "react" ] }, "scripts": { "build:js-main": "browserify -t [ babelify ] ./src/js/main/Main.js --exclude electron --im --no-detect-globals --node -d | exorcist ./src/assets/main.js.map > ./src/assets/main.js", "build:js-renderer": "browserify -t [ babelify ] ./src/js/renderer/App.js --exclude electron -d | exorcist ./src/assets

npm として配布するものは純粋な Node 機能のみで構成したいため脱 Babelしたが、Web フロントエンドや Electron では最新の ECMAScript 機能を利用したい。 というわけで、これまでは Babel + babel-preset-latest で JavaScript を変換してきた。しかし latest だと Web ブラウザーや Electron が最新規格に対応しても個別に変換を無効化するのが難しい。例えば ES2015 Classes は大半の Web ブラウザーが対応済みにも関わらず var Sample = function () { function Sample() { _classCallCheck(this, Sample); } } のように変換されてしまう。一方、機能単位で変換を無効にできるとしても Web ブラウザー毎の対応状況を調べる

話題の JavaScript Standard Style を試してみた。 背景 以前、以下の記事とはてブで JavaScript Standard Style を知った。 コーディング規則にJavaScript Standard Styleを使うべき4つの理由 - WPJ はてなブックマーク - コーディング規則にJavaScript Standard Styleを使うべき4つの理由 - WPJ はてブではセミコロンの省略に抵抗感のある人が多く私もそうだった。しかし同はてブで id:mysticatea さんが指摘されているように ESLint の no-unexpected-multiline でセミコロン省略時に問題のおきるコードを検出できる。また以下の理由からセミ コロンなしも案外よいものじゃないかと考えるようになった。 昨年末に Swift 入門してセミコロンのないコードに慣れた

自作 npm の開発で脱 Babel したときの対応と問題点まとめ。 2017/1/31 訂正 power-assert の作者、t_wada さんより power-assert は babel-register を通すなどしないと assert 置換が働かず素の assert になってしまうという指摘があったのでユニットテスト関連の記述を訂正 https://twitter.com/t_wada/status/826435235839504385 脱 Babel を決めた背景 私はいくつか自作 npm を公開している。これらは ES2015 以降の機能と構文を利用して npm publish の際に Babel で ES5 相当へ transpile している。この運用で特に問題も起きていない。またプリセットに babel-preset-latest を採用することで ES 関係の規格追

2011 年に書いた iOS で SQLite - FMDB の使い方という記事へ現在も結構なアクセスがある。 しかし当時は ARC すらなくサンプルとして古すぎる。なにしろ 5 年も前だし。また最近 iOS アプリ開発に戻ってきたこともあり、2017 年度の開発環境を学ぶ題材としてサンプルを再実装してみた。プロジェクトは GitHub に公開してある。 akabekobeko/examples-ios-fmdb: Example for the FMDB サンプル再実装における考察などは以下にまとめる。 開発方針 再実装にあたり開発方針を。 サンプル プロジェクトの機能と UI は元記事の内容を踏襲 Objective-C と Swift の両方を実装 FMDB は CocoaPods で管理 ユニット テストを実装する なるべく最新の Objective-C と Storyboard

これまで ESDoc の設定は esdoc.json に定義していたが昨年末にリリースされた v0.5.0 から他の形式もサポートされるようになった。CHANGELOG.md には .esdoc.json in current directory .esdoc.js in current directory esdoc property in package.json とある。これらの内、とくに嬉しいのは 3 番目の package.json。私はプロジェクト設定をこのファイルへ集約する派であり Babel や Browserify もそうしている。 実際に ESDoc 設定を package.json へ定義して npm-scripts から呼ぶ場合は以下のように記述する。 { "esdoc": { "source": "./src/js", "destination": "./esdo

以下の記事とはてブを受けての所感。 【翻訳】 2016年にJavaScriptを学んでどう感じたか - Endo Tech Blog はてなブックマーク - 【翻訳】 2016年にJavaScriptを学んでどう感じたか - Endo Tech Blog JavaScript による Web フロントエンド開発環境について総括する記事があると、はてブでは拒否反応が多く見られる。特にフレームワークやライブラリの乱立や JavaScript/CSS の Transpiler 周りに忌避感があるようだ。 確かに複雑である。しかし「それが何の問題を解決しているのか？」に注目すれば単純な要素技術の集合であることが理解できるはず。 例えば Browserify、webpack、Babel などの Transpiler/Bundler 系と ES2015 や TypeScript の関係は、JVM や

gulp なしの Web フロントエンド開発から 1 年あまり。その間、特に問題もなく npm-scripts で Web フロントエンド開発を管理できているので、この間に得られた運用知見や所感などをまとめてみる。 npm-scrips とは？ 最近の Web フロントエンド開発では AltJS/AltCSSのビルドやリリース用イメージ作成などに Node.js + npm を利用することが一般化してきた。そのためプロジェクトは package.json で管理することになる。package.json の提供する代表的な機能として プロジェクト情報の定義 プロジェクトの成果物を npm として配布するための情報 プロジェクト名、バージョン、作者などのメタデータを定義する 依存モジュール管理 プロジェクトが依存する npm とバージョンを管理する この情報へ基づき npm install コ

/** * Output log. * * @param {String} message Message text. */ function func(message) { console.assert(typeof message === "string", 'Invalid JSDoc: typeof message === "string"'); console.log(message); } に変換される。型チェックが偽ならば、その情報を assert として出力。Firefox や Chrome の開発者ツールであれば関数の呼び出しと assert 箇所をコンソールから確認できるので不正な値を指定した処理を修正するためのヒントになる。 環境構築と注意点 jsdoc-to-assert は本体と Babel plugin/preset 版が提供されている。plugin が Bab

先月、WordPress に Markdown と highlight.js という記事を書き、少しずつブログ記事の Markdown 化に取り組んでいた。しかしあまりにも定型作業 & 数が多いので移行補助ツールを開発することにした。 WordPress は標準で記事を XML としてエクスポートする機能がある。これを解析して Markdown ファイルに変換。そんなコンセプトで開発してゆ、私的に実用十分なものができたので wpxml2md としてリリースしてみた。 wpxml2md akabekobeko/npm-wpxml2md 以下に wpxml2md の説明や開発で得られた知見などをまとめる。 wpxml2md の使い方 まずは想定環境から。 WordPress の記事を Markdown で書く方法はいくつかあるが、このツールでは Jetpack by WordPress.com