その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

情報共有システム (Wiki みたいなやつ) に求めること

いま所属している組織で使っている情報共有システムが僕はいまいち好きではなくて,気に食わないところを twitter にガーッと書いたんだけど,さてここで「良い情報共有システムとは」と考えた時にスッと言語化出来なかったので,僕の思う情報共有システムに求めることをここでまとめておくことにする.

エディタが腐ってない

これは本当に重要で,エディタが腐っていると「Wiki を書こう」という気がそもそも起きないし,起きたとしてもエディタがストレスフルだと文章を書き始めてすぐに嫌になってしまうので最低限エディタはまともである必要がある.さもなくば Wiki は廃墟と化す.
WYSIWYG なエディタを利用するのは難しいと思っていて,本当に使いやすい WYSIWYG エディタを作るというのはかなりコストが高い (WYSIWYG エディタはある程度まで完成度が高まっていないと使い物にならない気がする) ので,システム側がマトモなエディタを用意してくれている可能性は高くはない.あと WYSIWYG の場合は見たままが成果物に反映されるから,誰かにとって使いやすいものでも他の誰かにとっては使いにくいという事が起きやすいと思っていて,組織全体にとっての使いやすさを最大化するのが難しい気がする.
そうなってくると,何らかの記法 (Markdown やそうした類のもの) に対応してそれを用いて書くのが良いのかなと思うし,僕はそれで良いんだけど,エンジニア以外の人にとってそれは本当に使いやすいのかな? という懸念はあって,難しいところだと思う.だからと言って,1つのページについて或る人は WYSIWYG で書いて,また或る人は Markdown で書く,みたいなハイブリッドな方法を採用すると大体カオスな事になって不幸が起きるという印象しかない.しかしこのへんに上手い解決法が提供されると幸せそう.
あとブラウザ内にエディタがあるというのは,エディタがブラウザのキーボードショートカットを奪ったり,或いはブラウザに奪われたりするから難しい気もしていて,そうなると既にある文章を API 経由か何かで送りつけられるのが良いのか,もしくはネイティヴなアプリがあると良いのだろうか? とか思うけどここらへんは良く分からない.一方でブラウザから編集できないと,資料を見ながら「ここ間違えているからスッと直そう」みたいな感じでカジュアルに編集しようとする意識をサポート出来ないから,ブラウザで編集可能である必要自体はありそう.でも GitHub を使っている時にブラウザから README.md を直接編集したくなる事はあまり無い気がする.文化の違いだろうか?

まあ,ストレス無くブラウザでページを編集できれば問題は無さそう.

ページ内の配置がある程度規約に縛られている

Wiki のページはその人の芸術性とかを反映する必要はあまりないはずなので,ある程度規約で縛られていたほうが良いと思う.
「ページ内のここを見たら必ずこれがある」だとか「時系列はページの上の方が新しくて下に行くほど古い」だとか,そういう基本的なことは全ページで共通していたほうが良くて,それは規約のようなものになっているべきだと思う.そうした規約があることで全てのページで「これが欲しい時はここを見ると良い」という共通の認識ができるので,欲しい情報へのアクセスが高速に行えて良いと思う.

自由に HTML を記述できて,自由な場所に自由に要素を置ける,みたいな機能は Wiki だと地獄を生むと思う.

URL の構造が予想しやすい

これは良い API の設計にも似ているけれど,各ページへの URL があまりに自由だと使いにくいと思う.
例えばプロジェクトのトップページは URL パスの親になっていて,その下にそのプロジェクトの各ページや子プロジェクトのページがぶら下がっていて,子プロジェクトはさらにその構造を持っているみたいな感じが使いやすいと思う.全部がフラットな構造になっていて,ページのタイトルがそのままパーマリンクのパスになっているとかはファンキーだけど使いにくいという感想しか無い.

僕はブラウザの URL 窓にプロジェクト ID を打ち込んで,そこから検索履歴に基いて見たいページを絞り込むという方法で特定のページにアクセスすることが多いので,URL に規則性が無いとそれが出来なくて大変な気持ちになる.

検索可能

説明不要だと思う.21世紀の Wiki全文検索できないと使いものにならない.
あとは「このプロジェクト内の文書だけ検索」みたいな,検索対象を絞れればあまり不満がないけど,検索オプションが多いと便利そう.

添付ファイルをまとめて管理できる

いま所属している組織では PowerPoint や PDF といった様々なファイルが Wiki にアップロードされ,日夜それらのファイルが更新されていきながら,それを見ながら,というスタイルで仕事が行われているので,添付ファイルを一括で管理できると便利.
例えば「企画.pptx」はプロジェクト内のあのページにあるけれど,「デザインガイド.pdf」はプロジェクト内の別のあっちのページにある,みたいな感じになっていてファイルがガンガン増えてくると,いざ「あのファイルが欲しい」となった時にどこに行けば良いのか分からなくて非常にストレスが溜まる.プロジェクト内の添付ファイルを一覧できる機能があれば,とにかくそこに行ってファイルを GET すれば良いので楽だと思う.

他サービスとの連携がしやすい

ページを更新したりした時に,なぜだかメールを飛ばしたがる Wiki が多いように思うけど,メールで飛ばされてもどうせ見ないし,どうしようもないと思う.それだったらチャットやら他のツールやらに飛ばせる方がどう考えても便利だし,その口があらかじめ用意されていると気持ちが良いと思う.更に自分で拡張も書きやすかったらなお良い.

ここまで書いてから気づいたんだけれど,これはイベントに対応する API がちゃんと提供されていれば良いということになった.

その他

と色々書いたのだけれど,Wiki のようなものはエンジニアだけでなく,あらゆる人が使うし,むしろエンジニアでない人の方が多く使う為,エンジニアが使いやすさを追求してもエンジニアでない人にとっては使いにくくなってしまって,全体的な作業効率は悪くなってしまうかもしれない *1.しかし導入する Wiki システムや BTS システムを選定する人は大体エンジニアが中心になっていて,そうした時にどのようにしてフラットな目線で,かつ明確な判断基準を持って選定すべきなのかというところが気になる.

個人的に,情報共有システムについて特に重視すべき点は「記事の作成・更新にストレスが無いかどうか」と「情報へのアクセスがストレス無くスムーズに行えるかどうか」だと思っている.

とにかく僕はここに列挙したような機能が情報共有ツールに付いていてくれると嬉しい.気づいていないだけで,あるいは忘れているだけで,他にもあった方が良い機能はあるかもしれないので,他の人の意見についても大変興味がある.

あと,最高の情報共有システムがあったら教えて下さい.よろしくお願いします.

追記

マジで重要な奴を忘れていた

*1:エンジニアでもない限り,イベント API を使ってアレやコレやしたい,みたいなことは思わないと思うし……

perl6 の環境を手っ取り早く構築してサクッと Hello world する

本記事はサクッと perl6 (rakudo) が動く環境を作って,ズバッと Hello world してみるというやつです.
早速行ってみましょう.

1. rakudobrew をインストールする

rakudobrew をインストールします

rakudobrew というのは perl5 で言うところの perlbrew/plenv,ruby で言うところの rvm/rbenv のようなものです.
なぜこうした物を使うかというと,perl6 は開発が非常に活発な言語であるためにデイリーで変更が入っていて,直っていたり壊れていたりするためです.
2015年10月現在,perl6 をやるときは rakudo と MoarVM は HEAD を使うというのが紳士の嗜みとなっています *1

というわけで入れましょう.

git clone https://github.com/tadzik/rakudobrew ~/.rakudobrew
echo 'export PATH=~/.rakudobrew/bin:~/.rakudobrew/moar-nom/install/share/perl6/site/bin:$PATH' >> ~/.bash_profile
echo 'eval "$(rakudobrew init -)"' >> ~/.bash_profile
exec $SHELL -l
2. MoarVMをビルドする

MoarVM というのは perl6 の VM です.これをビルドするとその VM 上で rakudo を走らせられるようになります.

rakudobrew build moar

そこそこ時間がかかります.待ちましょう.

3. panda をインストールする

panda というのは perl5 で言うところの cpan/cpanm,ruby で言うところの gem のようなものです.
別にこれを入れなくても Hello world 程度なら可能ですが,現実的にライブラリが使えないと話にならないので入れます.

rakudobrew build-panda
4. プログラムを書く

ここまで来るともう perl6 が実行可能となっていますから,あとは Hello world するだけです.
プログラムを書きましょう.

use v6;

say 'Hello world!';

use v6; というのにテンションの上昇を禁じえませんね!
それでは満を持して実行.

perl6 hello.p6

動きましたか? 動きましたね.やりました! 実績解除です.


これであなたも立派な perl6 野郎です.
あとは Perl 6 Documentation を覗いたり,Perl 6 Design Documents を愛でたりして頑張りましょう!
perl6-users-jp/perl6-examples · GitHub を眺めると,perl6 の全体を俯瞰できて良いかもしれませんね.


以上です.

*1:バージョンの切り替えとかも出来るっぽいけど使ったことがない.常に HEAD で生きているから……

Released IO::Blob for perl6

Released IO::Blob.


This is a perl6 module which provides IO:: interface for reading and writing a Blob.
IO::Blob inherited from IO::Handle, means it supports to handle a Blob like a filehandle (writable, readable and seekable).
For example, in case of you want to buffer string without real file, IO::Blob will help you to do that.

This module is inspired by perl5's IO::Scalar so basic usage is almost the same.

Please see documentation for more details.
https://github.com/moznion/p6-IO-Blob/blob/master/README.md


Enjoy!

perl6 の正規表現の or (|) は longest match

perl5 での正規表現の or は | のみでした.以下のように使うことができます.

'aaabbb' =~ /(a|a+b)/

これは a にマッチします.左に書いてあるマッチャが優先されますね.


同様に | を用いて perl6 で書いてみましょう.

'aaabbb' ~~ /(a|a+b)/

おおっと,これは aaab にマッチしてしまいます.
何故かと言うと perl6 の | は longest match だからなんですね.すごいぞ,これは便利!!!!

しかし上の perl5 の例と同じような挙動をさせたい場合もあるでしょう.まあ大体はそうですね.
そういう時は | の代わりに || を使うとよろしい.

'aaabbb' ~~ /(a||a+b)/

こうすると a にマッチします.やりましたね.

GitHub のリポジトリページにアクセスするだけで自動的に git clone される Chrome 拡張書いた

GitHubリポジトリページにアクセスするだけでローカルに git clone される Chrome 拡張を書きました.ggc という略称になりますが,まあなんかこれ紛らわしいですね.

なぜこんなものが必要になったかというと GitHubリポジトリ内検索は割と結果がひどくて,手元に clone してきてから grep なりなんなりをかけた方が必要なものを得られる可能性が極めて高い,というのがあるためです.
そんでもっていちいち clone するっつうのもダルいので,それだったらブラウザでリポジトリのページにアクセスした瞬間に自動的に clone すればいいじゃーん,もう2015年なのでストレージとか気にせず豪快にいこうやガッハッハ,という方法に id:s5r 氏と話していて辿り着いたのでそれを実装したというのが経緯になります.


Chrome 拡張を名乗っていますが,実態は Chrome 拡張 + サーバサイド実装という風になっています.
Chrome 拡張から直接コマンドラインを叩くのは不可能では無さそうだったけれど割とへんてこりんなステップを踏まなければならなそうな上に,Chrome のバージョンが変わったらここらへんガンガンぶっ壊れるんだろうな〜という憂慮があった為,ローカルにサーバを立ち上げておいてそのサーバに対して Chrome 拡張から AjaxAPI を叩く,というシンプルな構成になっています.


サーバの実装は go で書いていて,GitHub Releases でバイナリを配っているので,ダウンロードしてきてシュッと立ち上げることが可能です.
拡張本体の実装はこうしたアプリケーションの特性から Chrome Web Store とかにはリリースしてません.GitHub に置いてるだけですので適宜インストールしてご利用ください.


clone 先のディレクトリの構成は ghq と統一しているので,サーバの --dir オプションで clone ディレクトリの先を ghq のディレクトリと繋いでおくと色々多幸感があるかもしれません.


また,オプションとして github.com 以外のドメイン,例えば社内 GitHub Enterprise に対応させるための設定機能などが入っています.詳しくは README などを読んでいただけると良いかと思います.


とにかくこの拡張を有効にしておくと自動的にたくさんのリポジトリが降って来るのである種の快感があります.そして便利.
この便利さは Disk Full を味わうまでは続くことと思われます.あるいは超巨大リポジトリを無意識のうちに踏んでアアアア,みたいな感じになるまでは.

ほどほどにご利用ください.


[追記]

[追記2]

流石に自動で Clone するのはつらい (場合がある) という指摘を id:gfx 氏から受けたので,そこらへん設定出来るようにしました.

f:id:moznion:20150925111919p:plain

これを disabled (なんとデフォルトが disabled になった) にすると,

f:id:moznion:20150925105020p:plain

Clone URL の下にボタンが出るようになるので手動で clone が出来るようになる.

[追記3]

ghq とディレクトリ構造が揃っているという地味な違いがあったり.
まあこまけえこと気にせず Auto Clone Mode で使えば良いと思います!!! 自動クローン最高!!!!!!!!!!

Java で 任意個の文字を何らかのデリミタ区切りで記述した文字列がサクッと欲しいみたいなとき

こう書くと手っ取り早そう.

IntStream.rangeClosed(1, 10)
    .mapToObj(ignored -> "?")
    .collect(Collectors.joining(",")); // => "?,?,?,?,?,?,?,?,?,?"

次世代っぽい!!!

[追記]
id:nowokay さんから以下の方が良いのではという指摘が.確かに分かりやすい!

Stream.generate(() -> "?")
    .limit(10)
    .collect(Collectors.joining(","));

[追記2]
ちなみに gs-collections だとこう書けるとのこと.

Interval.oneTo(10)
    .collect(ignored -> "?")
    .makeString(",")

簡単ですね!

[追記ここまで]


以下やりとりとなります.

moznion [7:52 PM]
n個の”?”を”,”区切りで記述した文字列がサクッと欲しい,みたいな時に便利な奴ってありますか
List作ってString.joinとかが楽なのだろうか……

tokuhirom [7:56 PM]
それね
IntStream.rangeClosed(1,5).map(“,”).collect(Collectors.joining(“,”))
的な感じ

moznion [7:56 PM]
oh!

tokuhirom [7:56 PM]
おかしいけどw

moznion [7:56 PM]
ナウい書き方に見えますねw
map(“?”) か

tokuhirom [7:58 PM]
.map(n -> “?”) が正しいが
join(“,”, map { “?” } 1..10 )
と同じこと
まあ perl なら `(‘?’) x 10` だけどな!

moznion [7:58 PM]
そうすねw

tokuhirom [8:01 PM]
そういえば
TinyORM に QueryTerm.in() みたいなのを
いれたくて
入れたいな、とは思っているw

moznion [8:02 PM]
IntStream.rangeClosed(1, 10)
.mapToObj(ignored -> "?")
.collect(Collectors.joining(","));
出来た〜〜
そしてIN句を組もうとしていたことがバレバレであるw

xaicron [8:06 PM]
IN いがいでなかなかそのシチュエーションないからなーw