anyenv + ndenv を試す - アカベコマイリ
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
npm rewire を試す - アカベコマイリ
最近 React SFC (Stateless Functional Components) や Redux の影響を受けて、ES.next な環境でもクラスより関数で実装するようにしている。ES Modules であれ Node であれ個別に関数を外部公開できるからクラスを使用せずとも実装には十分だし、むしろ関数を積極的に採用することで外部依存を引数に限定できる。 しかし困ったことが。非公開の関数を単体テストする手段がない。 そもそも非公開なものをテスト対象とするのは悪手では？と言われればそのとおり。しかし公開関数が単一単純でも内部で多くの非公開な関数へ依存しているなら、それらを個別に単体テストしたくなるだろう。外部からみたら公開関数を単体テストしているつもりでも実際には結合テストなわけで。 クラスなら今のところアクセス指定子がないため、非公開メソッドは命名を工夫する慣習 (アンダースコ
redmine.tokyo 14 で登壇してみた - アカベコマイリ
2018/5/26 (土) に redmine.tokyo 14 へ参加 & 登壇。以下、レポっす。 第14回勉強会 - redmine.tokyo 2018/5/26 第14回勉強会 - redmine.tokyo #redmineT - Togetter 開場前 最寄りは都営浅草線の泉岳寺駅だが、自宅からのルートだと乗り換えが面倒なので京浜東北線の田町駅へ 田町駅で昼食、「いろり庵きらく」の「板そば」を頼んだらボリュームかなり多くて食べきれるか心配だったので飲み込む感じで処理 国際興業三田第 2 ビル、休日なので通用口から入るとのことだが案内してくれる方がいたので迷わず入れた 会場には 12:30 ぐらいに到着、着席 開始までの時間に持参 PC のプロジェクター接続確認してほしいとのこと ここでケーブル忘れに気づく、というか会場にあるのを期待する他力本願メソッドにも程があって、つまりは
CSS Modules をもっと試す - アカベコマイリ
業務プロジェクトへ 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 プロセスともに
Sass を試す - アカベコマイリ
年末に PostCSS + cssnext と CSS Modules を試したのだが、コメ欄の指摘とそれを受けた追記を読んでもらえるとわかるとおり次世代 CSS 仕様の先取り = CSS.next のつもりで導入した cssnext が微妙だと感じはじめている。 cssnextを使うべきか - yuhei blog QiitaのCSS構成2017 - Qiita これらの記事でも言及しているとおり cssnext の採用する PostCSS プラグイン は CSS Working Group の認知していなかったり取り下げられそうなものもある。前者は直せばよいけど後者については直近の仕様だと冗長な記述が避けられないことを意味している。私は少なくとも モジュール管理 @import が URL ではなくモジュール参照として解決される 変数 (定数) と Mix-In 色やサイズなどを変数
PostCSS + cssnext と CSS Modules を試す - アカベコマイリ
このあいだ書いた記事の締めで予告したとおり 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
Electron を試す 11 - webpack によるビルド - アカベコマイリ
これまで Web フロントエンドや Electron の JavaScript ビルドには Browserify と Babel を使用してきた。しかし Browserify の開発は停滞している。現在は個人から org 運営へ移管しており browserify/discuss にて開発者の募集や議論もおこなわれているものの、往時の勢いはない。 私としては CLI のみで完結して設定を package.json に集約しやすい点から Bundler の中では Browserify 推しだった。しかし今後のことを考えると webpack に移行したほうがよいと判断せざるをえない。 というわけで Electron プロジェクトの開発環境に webpack を導入してみた。以下はその覚書。 サンプル プロジェクト akabekobeko/examples-electron Browserify
Electron を試す 10 - Main プロセスのデバッグ - アカベコマイリ
$ 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
npm 開発で再び Babel を導入することにした - アカベコマイリ
以前、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 の構成例。
babel-preset-env と minify - アカベコマイリ
{ "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
babel-preset-env を試す - アカベコマイリ
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 ブラウザー毎の対応状況を調べる
npm 開発で脱 Babel してみる - アカベコマイリ
自作 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 関係の規格追
iOS で SQLite - FMDB の使い方 2017 - アカベコマイリ
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 の設定を package.json に定義する - アカベコマイリ
これまで 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
Redmine 運用について 3/3 - 普及の施策と課題 - アカベコマイリ
Redmine 運用について書いてみるシリーズ 3/3。最終回は Redmine に馴染みないユーザー、例えば工程管理やバグ表を Excel で運用していたとか、そういう管理職や社員に対して Redmine を普及させるための施策や課題などを書く。これまでの内容と重複する部分もあるが、本記事ではルールよりも事例や留意したことに重きを置く。 現状分析 前職はソフトハウスであり、一部に Trac による TDD を経験していたプロジェクトもあったので Redmine 導入はスムーズ。TDD に親しみのない社員も BTS として利用しはじめて Excel ベースのバグ表を置き換えながら慣れていった。 一方、現職は私が移籍する前に Redmine を導入していたものの数名が実験的に利用しているような状況。業務は主に上長の手による Excel シートで管理されていた。シートには部署に属する社員と担当
ES6 コードをテストする - アカベコマイリ
ES6 で書かれたコードをユニット テストしたい。できればテスト自体も ES6 で。という希望を実現してくれそうなツールがあったので試してみる。 mocha ユニット テストには mocha を利用する。業務で Node モジュールのテストに利用していて馴染みがあるのと後述する espower-babel が mocha を想定しているのがその理由。 mocha を npm test や npm run から利用するならインストールはローカルだけでよい。package.json 管理下にある npm にはパスが通った状態になる。 余談だが以下の記事を読んで gulp などもローカルにインストールして実行を npm で抽象化するほうがよいのでは？と考えるようになった。 npm で依存もタスクも一元化する 記事中にもメリットとして説明されているとおり利用者は npm だけ覚えればよい。グローバ
ESDoc を試す - アカベコマイリ
すると esdoc ディレクトリ内に解析結果となる HTML ファイルなどが出力される。 ESDoc をプロジェクトのローカルで使用する 最近 npm はなるべくプロジェクトのローカルにインストールしている。グローバルだと npm が更新されたときに依存しているプロジェクトすべてが影響を受ける。互換性の問題が起きたりしたら一大事だ。プロジェクトのローカルならそのような心配は無用である。 package.json で npm バージョンを管理することで、プロジェクトが必要とする依存も明示できる。ファイルを Git リポジトリなどで管理していれば環境の共有や復元も容易だ。 というわけで ESDoc もローカルへインストール。package.json の置かれたディレクトリで以下のコマンドを実行。ESDoc は開発用なので -D オプションをつけて package.json の devDepen
gulp なしの Web フロントエンド開発 - アカベコマイリ
Web フロントエンド開発において gulp は非常に便利だ。しかしあまりにも gulp に依存しすぎており、これなしで開発できるだろうか？という不安もある。というわけで gulp を利用せず package.json と npm だけで同等の機能を実現する方法を検討してみた。 2015/11/4 追記 babelify v7.2 を試すで babelyfy 7.2 ( とその中の Babel 6.x ) について調べ、npm-scripts の変更が必要なことを確認したので追記。また Windows 環境の動作検証をおこなったところ、最新の watchify なら -o オプションが通ることを確認できた。よって本記事の最後の課題が解決したことになる。 2015/9/23 追記 cpx と rimraf を試すの内容をファイル処理に反映して簡略化。 2015/9/15 修正 Stylus
npm-scripts で Web フロントエンド開発を管理する - アカベコマイリ
gulp なしの Web フロントエンド開発から 1 年あまり。その間、特に問題もなく npm-scripts で Web フロントエンド開発を管理できているので、この間に得られた運用知見や所感などをまとめてみる。 npm-scrips とは？ 最近の Web フロントエンド開発では AltJS/AltCSSのビルドやリリース用イメージ作成などに Node.js + npm を利用することが一般化してきた。そのためプロジェクトは package.json で管理することになる。package.json の提供する代表的な機能として プロジェクト情報の定義 プロジェクトの成果物を npm として配布するための情報 プロジェクト名、バージョン、作者などのメタデータを定義する 依存モジュール管理 プロジェクトが依存する npm とバージョンを管理する この情報へ基づき npm install コ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CocoaPods を試す - アカベコマイリ