npm icon-gen v1.2.0 release - アカベコマイリ
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 をそ
babel-preset-babili を試す - アカベコマイリ
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-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-scripts で Web フロントエンド開発を管理する - アカベコマイリ
gulp なしの Web フロントエンド開発から 1 年あまり。その間、特に問題もなく npm-scripts で Web フロントエンド開発を管理できているので、この間に得られた運用知見や所感などをまとめてみる。 npm-scrips とは？ 最近の Web フロントエンド開発では AltJS/AltCSSのビルドやリリース用イメージ作成などに Node.js + npm を利用することが一般化してきた。そのためプロジェクトは package.json で管理することになる。package.json の提供する代表的な機能として プロジェクト情報の定義 プロジェクトの成果物を npm として配布するための情報 プロジェクト名、バージョン、作者などのメタデータを定義する 依存モジュール管理 プロジェクトが依存する npm とバージョンを管理する この情報へ基づき npm install コ
jsdoc-to-assert を試す - アカベコマイリ
/** * 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
npm-scripts でクロスプラットフォームに環境変数を参照するための npm を作成してみた - アカベコマイリ
以下の記事で npm-scripts から環境変数を参照する方法と問題点について書いた。 Electron を試す 7 – Electron v1.0 対応 npm-scripts で自前の環境変数を利用する方法と問題 課題として npm run するプラットフォームによって変数の参照記法が異なるため、それらを統一できない問題がある。npm-scripts でタスク管理したい派としては、どうしても解決したい。そこで対策用 npm を作成してみた。 cross-conf-env akabekobeko/npm-cross-conf-env 以下に npm の設計などをまとめる。 npm-scripts における環境変数の参照記法 冒頭のリンク先でも解説してあるが、改めて。package.json に定義された値を npm-scripts から環境変数として参照する場合の記法は以下となる。 P
espower-babel から babel-preset-power-assert への移行 - アカベコマイリ
私は Web フロントエンドのテストで mocha + power-assert + espower-babel を組み合わせて利用しているのだが、これらのうち espower-babel が Deprecated になった。経緯と代替については以下の記事にまとまっている。 power-assert + babel as a development tool これからは espower-babel 代わりに babel-register と babel-preset-power-assert を利用。babel-register で require をフックして assert を power-assert へ置き換える。この処理が Babel ビルドの一環として実行されるようになった、という理解でよいのだろうか。 移行には npm 更新、.babelrc と mocha.opt 修正が必要
Electron を試す - 開発環境の構築 - アカベコマイリ
これまで NW.js を使ってきたが同じ Chromium + Node 系のフレームワークとして最近は Electron のほうが勢いあるようなので試したくなった。使用感を把握するため、まずは開発環境を構築してみる。 更新履歴 2015/11/5 npm-scripts を babelify 7.2 (Babel 6.x) を採用した内容へ更新。また最新 watchify の Windows 対応について追記した。これらの詳細については babelify v7.2 を試すを参照のこと。 2015/10/19 npm-scripts を最新へ更新、Main プロセスのビルド説明に Browserify の --node オプション解説を追加。 設計方針 package.json と npm だけを使用 AltCSS は Stylus を採用 ユニット テスト対応 コード ドキュメント対応
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
ESDoc を試す - アカベコマイリ
すると esdoc ディレクトリ内に解析結果となる HTML ファイルなどが出力される。 ESDoc をプロジェクトのローカルで使用する 最近 npm はなるべくプロジェクトのローカルにインストールしている。グローバルだと npm が更新されたときに依存しているプロジェクトすべてが影響を受ける。互換性の問題が起きたりしたら一大事だ。プロジェクトのローカルならそのような心配は無用である。 package.json で npm バージョンを管理することで、プロジェクトが必要とする依存も明示できる。ファイルを Git リポジトリなどで管理していれば環境の共有や復元も容易だ。 というわけで ESDoc もローカルへインストール。package.json の置かれたディレクトリで以下のコマンドを実行。ESDoc は開発用なので -D オプションをつけて package.json の devDepen
material-flux を試す - アカベコマイリ
React による Web アプリケーション開発で Flux に facebook/flux を採用していたけどシングルトンが扱いにくいので代替を検討した。 flummox Flux ライブラリを採用するにあたり単純であることを重視。規模が小さく簡潔で、その気になれば自分で書き直せるようなものがよい。機能としては Store/Action だけ管理できれば十分である。 次に ES6 (これからは ES2015 と呼ぶべきだろうか？) に対応していること。ライブラリの提供する Store/Action を利用するにあたり Object.assign() などの Mix-In 機構ではなく ES6 class の継承で書きたい。 すこし前に以下の記事を読み、これらの条件を満たすものとして acdlite/flummox を採用するつもりだった。 JavaScript - React0.13にお
ES6 コードをテストする - アカベコマイリ
ES6 で書かれたコードをユニット テストしたい。できればテスト自体も ES6 で。という希望を実現してくれそうなツールがあったので試してみる。 mocha ユニット テストには mocha を利用する。業務で Node モジュールのテストに利用していて馴染みがあるのと後述する espower-babel が mocha を想定しているのがその理由。 mocha を npm test や npm run から利用するならインストールはローカルだけでよい。package.json 管理下にある npm にはパスが通った状態になる。 余談だが以下の記事を読んで gulp などもローカルにインストールして実行を npm で抽象化するほうがよいのでは？と考えるようになった。 npm で依存もタスクも一元化する 記事中にもメリットとして説明されているとおり利用者は npm だけ覚えればよい。グローバ
gulp でアイコン フォント生成 - アカベコマイリ
今日の昼休み、はてブを見ていたら以下の記事がホットエントリーに入っていた。 sprite画像はもう終わり？gulpでIcon Fontをつくろう！ アイコン フォント生成に IcoMoon を利用しているのだけど gulp で同等の処理を実現可能なら SVG とビルド処理をリポジトリで一元管理できて便利だ。というわけで自分でも試してみる。 gulp-iconfont 冒頭にあげた記事ではアイコン フォントの生成に gulp-iconfont-css を利用しているが gulp.js plugin registry の検索だとヒットしない。調べてみたところ、このプラグインはブラックリストに入ってしまったようだ。リストには代替として gulp-iconfont が挙げられていたので今回はこちらを採用する。 プロジェクト構成 プロジェクト構成は以下のようにしてみた。 / ├ package.js
React.js を試す - ツリービュー - アカベコマイリ
前に書いた node-webkit を使ってみる 2 の最後で「簡単なファイラーでも作ってみようと思う」などと宣言したのだけど UI をなにで実装するか迷っていた。 ファイラーの UI は典型的なツリー ビューを採用するつもりだった。しかし長らく愛用してきた jQuery だと内部的なデータ構造と DOM を対応づけるような管理が面倒なのでファイラーみたいなものには向かなそう。 例えばツリーのどこかがクリックされて紐づく内部データを処理したいとるする。jQuery だと DOM 構築で要素の id や class にインデックスを割り当てておきイベント ハンドラで取得判定...という感じになるだろう。しかしこうした連携の仕組みを自前で実装するのはとても辛い。 jQuery、静的 HTML に対して簡単に装飾するならよいのだけど動的な部分が増えると難易度が跳ね上がる。いま仕事で取り組んでいる
単一の Xcode プロジェクトで複数ターゲットの iOS アプリをビルドする - アカベコマイリ
iOS アプリを開発していると共通の実装でコンテンツだけ差し替えた別アプリをリリースしたいことがある。例えばゲームならキャラクターやパラメータ、観光案内アプリであれば地図や写真を土地ごとに変更する、など。 このような対応をおこなう場合、外部スクリプトでコンテンツ部分を差し替えるとかリポジトリのブランチを利用してプロジェクト構成を切り替えるのかと想像していた。しかし調査してみたら Xcode の標準機能だけで実現できたので方法をまとめておく。 Xcode プロジェクトのターゲット管理 Xcode で iOS アプリのプロジェクトを作成すると初期状態ではターゲットがひとつだけ指定されている。これを複数にする手順は以下。 Xcode でプロジェクトを開く 画面左の Project Navigator 上でプロジェクトを選択 右側に表示された TARGETS 欄のターゲットを選択して、コンテキスト
iOS の動画再生を試す - アカベコマイリ
iOS アプリで動画を再生しくなったので方法を調べてみた。標準の動画再生 API としは MPMoviePlayerController と AVPlayer の 2 種類が提供されている。そのため両方を利用したサンプルを実装してみる。 再生対象となる動画の選択 はじめに再生対象とする動画の選択方法について考える。 最も簡単なのはアプリ内のリソースとして動画ファイルを組み込む方法である。しかし静止画に比べ動画はかなり大きいため、アプリのサイズに影響する。再生対象が固定になる点もイマイチ。そこで今回はカメラロールから動画を選択するようにしてみる。先月書いた iOS でグリッド表示という記事で作成したサンプル プログラムを元に動画だけ選択する画面を実装。 今回のサンプルでは対象とするグループを ALAssetsGroupSavedPhotos に限定して ALAssetsGroup でコンテン
さくらのVPS を改めて使いはじめる 1 - 使用準備、SSH 公開鍵認証 - アカベコマイリ
ブログ移転でドメインを維持できなくなる点については目をつぶることにした。そもそも akabeko.sakura.ne.jp はさくらのインターネットの提供するサブドメインなので固執する意義が薄い。むしろこのままリンクが集まり続けたら移行の枷は重くなるばかりである。 というわけで akabeko.sakura.ne.jp はあきらめて新たに akabeko.me という独自ドメインを取得することにした。 余談だが私のハンドル名であるアカベコは偶蹄目なので本当は .mo ドメインにして akabeko.mo にしたかったのだけど .mo は維持費がけっこう高いため .me で妥協。 用意するもの サーバー上で作業をおこなうため、まずは SSH クライアントを用意。Windows なら TeraTerm、Mac の場合は標準のターミナルを利用する。 ファイルの送受信については SSH クライアン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Electron を試す 7 - Electron v1.0 対応 - アカベコマイリ