はてなブックマーク

Redmine 運用について書いてみるシリーズ 3/3。最終回は Redmine に馴染みないユーザー、例えば工程管理やバグ表を Excel で運用していたとか、そういう管理職や社員に対して Redmine を普及させるための施策や課題などを書く。これまでの内容と重複する部分もあるが、本記事ではルールよりも事例や留意したことに重きを置く。 現状分析 前職はソフトハウスであり、一部に Trac による TDD を経験していたプロジェクトもあったので Redmine 導入はスムーズ。TDD に親しみのない社員も BTS として利用しはじめて Excel ベースのバグ表を置き換えながら慣れていった。 一方、現職は私が移籍する前に Redmine を導入していたものの数名が実験的に利用しているような状況。業務は主に上長の手による Excel シートで管理されていた。シートには部署に属する社員と担当

以下の記事に触発され、私の実施している Redmine 運用についてまとめたくなった。 Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例 しかし書いているうちにものすごく長くなってしまったので、全 3 回へ分割することした。 初回は自身と Redmine の関わりについて。どのような立ち位置から書かれているのかを前置きすることで、読者は自身との距離感を意識しながら記事を読めるのではなかろうか。Redmine 導入を提案するのであれば先行事例として参考に。提案されている側なら相手がどのような背景や思想をもっているかを理解するのに役立つ、というのが本記事の狙い。 私の Redmine 運用経験 私は前職も含めると足掛け 6 年ほど Redmine を運用してきた。バージョン更新などの環境構築や運用ルール策定なども含む、システム管理者として活動している

Redmine 運用について書いてみるシリーズ 2/3。今回は職場の Redmine を運用するためのルールと諸設定をまとめる。守秘義務に抵触しそうな内容を避けるため、ぼかして書いているところもあるが主旨には影響していないはず。 システム管理者 システム管理者とは Redmine のユーザー管理画面においてシステム管理者が有効になっている状態を指す。プロジェクトの管理者とは別なので注意すること。この権限を持つユーザーは Redmine のあらゆる設定を変更できる。 Redmine を運用するにあたり、少なくとも 1 名 (1 ユーザー) は必要になる。 任命するのであれば Redmine のインフラと機能の両面に通じているユーザーであることが望ましい。とはいえ Redmine の動作環境は Ruby だけでなく Passenger や HTTP サーバー、DBMS も絡み複雑。もしこれらの

以下の記事で 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

Electron を試す 7 - Electron v1.0 対応で npm-scripts に環境変数を定義してそれを scripts 内から参照する方法を書いたのだが、この方法は Windows 環境だと利用できない。 と、これだけで話を終えるのはもったいないので、私がおこなった調査や見解についてまとめる。 2016/5/19 追記 本記事の問題を解決するための npm を作成した。詳しくは npm-scripts でクロスプラットフォームに環境変数を参照するための npm を作成してみたを参照のこと。 package.json の config package.json に config の説明がある。 A "config" object can be used to set configuration parameters used in package scripts that

ねんがんの Electron 1.0 をてにいれたぞ！というわけで akabekobeko/examples-electron のプロジェクトを対応させてみた。その過程で得られた知見を記録しておく。 2016/5/16 補足 v1.0 からわずか数日で v1.1 がリリースされた。この記事に関係する変更点は Devtron の読み込み改善ぐらいである。examples-electron のプロジェクトは既に v1.1 を参照するように修正済み。 モジュール参照の変更 従来の Electron ではアプリケーション情報となる app やシェル操作に必要な shell などは直に参照していた。

これまで Stylus から Normalize.css を利用する場合、以下のように管理していた。 bymathias/normalize.styl から normalize.styl をダウンロード プロジェクトの src/stylus/lib フォルダ内に normalize.styl を配置 Stylus のエントリー ポイントで @import "lib/normalize.styl" つまり静的リソースとして扱い、バージョン更新があれば手動で置き換えていた。面倒な作業だが、CSS では JavaScript における npm と Browserify/webpack のようなリンカー的な仕組みが確立していないと考えており、また、更新も滅多にないことから放置していた。 しかしふと、Normalize.css のサイトをチェックしたら 公式 npm が用意されていた。また Styl

私は 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 修正が必要

Web フロントエンド開発で npm の世界に触れ、いつか自分も作成してみたいと考えてた。 そんな折 Electron アプリ用にプラットフォームごとにアイコンを用意するのが面倒に感じていた。SVG から PNG を生成してそれを個別のツールでアイコン化。それほど頻繁に発生する作業ではないが、ファイル形式さえ満たせればクロス プラットフォームにできそうな処理だ。これは npm の題材としてちょうどよいのでは？ということで、そういう npm を作成してみた。 akabekobeko/npm-icon-gen icon-gen せっかくなので開発の過程に得られた知見を記録しておく。今後、新たに npm 開発するとき役立つかもしれない。 機能と設計方針 はじめに npm が実現する機能と設計方針を明確にしておく。 対象とするアイコン種別は以下 ICO ICNS Favicon 単一の SVG フ

ElectronElectron を試す 12 - IPC を contextBridge へ移行するElectron を試す 11 - 簡易ファイラー with TypeScriptElectron を試す 11 - webpack によるビルドElectron を試す 10 - Main プロセスのデバッグElectron を試す 9 - Babel 変換を最小におさえつつ minifyElectron を試す 8 - electron-prebuilt のパッケージ名変更と BrowserifyElectron を試す 7 - Electron v1.0 対応Electron を試す 6 - 複数ウィンドウの管理Electron を試す 5 - Electron v0.35.0 対応Electron を試す 4 - 簡易音楽プレーヤー 2Electron を試す 3 - 簡易音楽プレ

Electron アプリにおける複数ウィンドウの生成と連携について考察してみる。 BrowserWindow とプロセス Electron のウィンドウは Main プロセスより BrowserWindow として生成される。 import Path from 'path'; function createWindow() { const w = new BrowserWindow( { width: 400, height: 400, minWidth: 400, minHeight: 400, resizable: true } ); const filePath = Path.join( __dirname, 'index.html' ); w.loadURL( 'file://' + filePath ); } 生成されたウィンドウ上で実行される JavaScript は Rend

Sublime Text の利用パッケージと設定 2015で予告したとおり Sublime Text に近い環境を Atom で構築してみる。対象は現時点の最新 Atom v1.2.4 とする。 パッケージ管理 Atom は標準でパッケージ管理機能が組み込まれている。追加と削除、検索、設定も GUI ベースなのでわかりやすい。 紹介しているパッケージを検索する場合はメニューから Atom > Preferences を選ぶと Settings タブが表示される。その左メニューから Install を選択して検索窓にパッケージをコピペした後 Enter キーを押す。 検索結果にはパッケージ情報と共にダウンロード数も表示されるため、評価の目安になる。パッケージ情報の Install ボタンを押すことでインストールできる。 検索結果として既にインストールしたパッケージも混在して表示される。ここか

2015/10/29 に JavaScript の Transpiler である Babel の 6.0.0 がリリースされた。 6.0.0 Released これまでの Babel はデフォルトで ES6 と React JSX 変換に対応していたが、これからはプラグイン化されたものを指定する形式になるのだという。Browserify 用 Babel の babelify も同様で、これを最新に更新してコンパイルを実行すると ES6 部分が SyntaxError になる。 $ npm run build:js-main > [email protected] build:js-main .../examples-electron/electron-starter > browserify -t babelify ./src/js/main/Main.js --im --no-

これまでのシリーズで Electron の開発環境が固まってきので実際にアプリを作成してみたい。サンプルとしてある程度の複雑さがほしいから以前に nw.js を使ってみる 5 - 簡易音楽プレーヤーで実装したものを移植することにした。 設計方針 移植にあたり単純に動かすだけなら NW.js 版の実装を Renderer プロセス部分へまるごとコピーするだけでよい。 しかし今回は Electron らしく Main/Rendrer を分割、ダイアログ表示や音楽ファイルのメタデータ読み込みは Main プロセスで実行させて Main/Rendrer 間の連携は IPC に限定する。 remote を利用すれば Main プロセス部分の機能を Renderer プロセスから簡単に呼び出せるけれど却下。便利な反面 Main/Renderer が密結合になりやすい。特に双方の Object を参照し

OS X を El Capitan に更新したら Rootless によって XtraFinder が利用できなくなった。つまり TotalFinder「XtraFinder がやられたようだな...」 TotalSpaces「奴は四天王の中で最弱...というか我々もやられたようだな」 というわけだ。 どうしても使いたい場合は Configuring System Integrity Protection で Rootless を無効化すればよい。しかしこの機能はセキュリティ対策を目的としているため、できればそのままにしたい。 XtraFinder から標準 Finder へ乗り換えて一週間ぐらいたった。その間、気になったところを書いておく。 タブ機能 XtraFinder は常にひとつ以上のタブがあり、新規タブ ボタンもその隣に表示されている。そのため初期状態からのタブ追加がクリックだけ

Electron を試すで残された課題を解決したので、その内容を記録しておく。 2015/10/5 追記 本記事のはてブにて id:Pasta-Kさんより .ico ファイルを反映させるために wine が必要との指摘があった。試してみたところ OS X 環境でもアイコンとバージョン情報変更を反映した Windows 向けパッケージを生成できたので追記した。 electron-packager の --icon オプションに .ico ファイルを指定すると OS X でエラーになる問題だが Windows 環境で実行したらパッケージ化に成功。一方、Windows 環境だと OS X 版のパッケージ化がスキップされる。Linux 版は特別なオプションがないためか OS X と Windows のどちらでもパッケージ化できた。 この状況から察するに、アイコンの埋め込み処理などでプラットフォーム

Electron の Starter プロジェクトで #7 Windows 版パッケージにバージョン情報リソースを含める を動作させるのに Node 以外で必要なものがあるため、それらの環境構築についてまとめる。 npm のなかに node-gyp というプラットフォームのネイティブ機能を利用するための npm を利用しているものがある場合、Windows 環境で npm install すると Python や CL.exe が見つからないというエラーが起きる。 これらを防ぐためには Node の他に Python と Visual C++ をインストールする。 Python Python のインストーラーは Download ページから入手。バージョンは 2.x 系と 3.x 系に分かれているのだが node-gyp が 3.x 対応していなさそうなのと Ansible など他のツール

これまで 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 を採用 ユニット テスト対応 コード ドキュメント対応

{ "scripts": { "release:css": "stylus -c ./src/stylus/App.styl -o ./dist/bundle.css", "release:js": "browserify -t babelify ./src/js/App.js | uglifyjs > ./dist/bundle.js", "release:clean": "trash ./dist", "release:mkdir": "mkdirp ./dist && npm run release:clean && mkdirp ./dist", "release:copyfiles": "copyfiles -f ./src/*.html ./dist", "release:copydirs": "ncp ./src/fonts ./dist/fonts", "release:c

CSS の text-align には justify という設定がある。これを指定するとテキストが均等に割り付けられて行末がそろう。しかし半角・全角文字の混在するテキストは Chrome や Safari などの WebKit 系 Web ブラウザー (現在の Chrome は Blink だけど) でうまく表示されない。過去に以下の記事を読み、そのように認識していた。 WebKit系ブラウザ（Chrome／Safari）で両端揃えはできないの？jQueryで検証してみた text-align: justify で日本語テキストも両端揃えにしたい！ しかし今日、なにげなく最新の Chrome で試したところ期待どおり均等割り付けされていた。WebKit 系の対応がイマイチということだったし Chrome は Blink 移行時に対応したのかもしれない。では現在も WebKit を採用する

以前 minimalflat という Redmine テーマを作成したのだが、このときは標準テーマの application.css を @import で取り込み必要なものだけ上書きしていた。 しかし変更する項目が多いなら上書きするよりフルスクラッチしたほうが効率的だし CSS の定義も Stylus へ移行したい。そのためコードベースを改めた新プロジェクトとして minimalflat2 を起ち上げることにした。 一ヶ月ほどかけて少しずつ開発。ひととおり実装を終えたので v1.0.0 をリリースしてみた。 akabekobeko/redmine-theme-minimalflat2 Releases 更新履歴 2015/9/24 v1.0.x 系リリースが更に増えたのでリンクを Releases に変更。 2015/9/8 リポジトリ画面でファイルやディレクトリ部分が中央寄せになる問題

gulp なしの Web フロントエンド開発 のコメント欄にて npm-scripts を Windows 環境でも並列実行させる方法として npm-run-all を勧められた。他にも CLI 周りのツールをいくつか教えていただき、その中にある concurrently も並列実行を実現するものなので、これらをまとめて試してみる。 2015/9/1 追記 npm-run-all v1.2.8 を試すにも書いたとおり最新の npm-run-all であれば watchify の終了問題は発生しない。よって現在の package.json では npm-scripts の実行を npm-run-all へ統一している。 元の npm-scripts npm-run-all と concurrently による書き換え対象となる npm-scripts は以下。 { "scripts": {

gulp なしの Web フロントエンド開発 の追補編として gulp を利用するケースもまとめておく。元記事と同じプロジェクトと機能を gulp で実装した。記事の構成は「gulp なしの〜」を踏襲。各項の説明は package.json の scripts に代わって gulp タスクとしている。 設計方針 はじめに設計方針を決めておく。 AltJS から JavaScript へのコンパイルに対応する AltCSS から CSS へのコンパイルに対応する ファイル監視による AltJS/AltCSS の自動コンパイルに対応する ユニット テストに対応する コードド キュメント生成に対応する Windows 環境を考慮する 単体 gulpfile.js のみで実装する 方針 1 〜 6 までは「gulp なしの〜」と一緒。方針 7 は環境に関する設定を package.json と g

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

この間の記事では Browserify による JavaScript の結合を試したが、この状態だとデバッグ対象が巨大な単一ファイルとなり扱いにくい。この問題の対策として今回は SourceMap の生成を試してみる。前回の gulpfile.js にはいくつかバグがあったので、ついでにそれらも修正しておく。 AltJS から JavaScript をコンパイルしたり Minify しても、デバッグ時には変換前の状態で扱いたい。そんな欲求に応えてくれる仕組みとして Source Maps がある。 Source Map Revision 3 Proposal Introduction to JavaScript Source Maps 変換前の情報を既定の書式で JavaScript ないしは別ファイルに記録しておくことで、対応しているツールが変換前後のスクリプトに関連づけてくれる。例えば

すると esdoc ディレクトリ内に解析結果となる HTML ファイルなどが出力される。 ESDoc をプロジェクトのローカルで使用する 最近 npm はなるべくプロジェクトのローカルにインストールしている。グローバルだと npm が更新されたときに依存しているプロジェクトすべてが影響を受ける。互換性の問題が起きたりしたら一大事だ。プロジェクトのローカルならそのような心配は無用である。 package.json で npm バージョンを管理することで、プロジェクトが必要とする依存も明示できる。ファイルを Git リポジトリなどで管理していれば環境の共有や復元も容易だ。 というわけで ESDoc もローカルへインストール。package.json の置かれたディレクトリで以下のコマンドを実行。ESDoc は開発用なので -D オプションをつけて package.json の devDepen

React による Web アプリケーション開発で Flux に facebook/flux を採用していたけどシングルトンが扱いにくいので代替を検討した。 flummox Flux ライブラリを採用するにあたり単純であることを重視。規模が小さく簡潔で、その気になれば自分で書き直せるようなものがよい。機能としては Store/Action だけ管理できれば十分である。 次に ES6 (これからは ES2015 と呼ぶべきだろうか？) に対応していること。ライブラリの提供する Store/Action を利用するにあたり Object.assign() などの Mix-In 機構ではなく ES6 class の継承で書きたい。 すこし前に以下の記事を読み、これらの条件を満たすものとして acdlite/flummox を採用するつもりだった。 JavaScript - React0.13にお

CSS や JavaScript で document.querySelector に指定する Selector を DOM Element から取得したくなって方法を調べていたら以下の記事をみつけた。 javascript - Get CSS path from Dom element Element を指定すると Selector を返すような API を想定していたのだが自前で Node/Element をチェックする必要があるようだ。動作の理解と実証のため簡単なサンプルを作成する。 以下のような HTML から <h1>、<p>、<th>、<td> がクリックされたとき、その Element から得た Selector を表示。Selector が正しいことを確認するために document.querySelector へ指定して得られた Element の背景色を変更する。 サン