“Perl::Lint - Yet Another Static Analyzer for Perl5”というタイトルでTPF助成金に応募しました
I proposed a tpf grant. I’m waiting for your feedback! #perl #tpf http://t.co/PUJLf4VIOR
— セカイ系 (@moznion) 2014, 3月 16
The Perl FoundationのGrants Committeeのルールが変わったそうで,折角の良い機会なのでGrantにProposalを出してみました.
TPF Grants Committeeのルールの変更については次の記事を参照してください.
TPFによるPerl助成金の交付の変更等について : D-7 <altijd in beweging>
提出したProposalの詳細は以下です.
http://news.perlfoundation.org/2014/03/grant-proposal-perllint---yet.html
ざっくりとこのProposalの内容を説明すると……
目的
Perl::Criticは大変素晴らしいモジュールであり,Perlで書かれたコードの品質向上に一役買っている.しかしながら現状のPerl::Criticは処理が重く低速である為,気軽にCritic処理を回す *1 ことに対する心理的障壁は高い.
そこで本プロジェクトではPerl::Critic互換の新しく,なおかつ高速なモジュールであるPerl::Lintを作成する事を目的とする.
手法
Perl::Criticはソースコードの解析にPPIを利用している.PPIとはPure Perlで記述されたPerlの解析器 (Tokenizer & Parser) のことである.Perl::LintではC++で記述されておりPPIよりも高速なCompiler::Lexer並びにCompiler::Parserを解析器として使用することによって高速化の実現を図る *2 *3 *4.
本プロジェクトに類似した応用例としてPerl::MinimumVersion::Fastが存在する.当該モジュールはCompiler::Lexerを使用しており,PPIを使用しているPerl::MinimumVersionと比較して30倍程度の高速化を実現している *5 *6.したがって本プロジェクトでも同様の効果を期待できる.
……という感じになっています.
TPFのブログ記事の方で目下フィードバックを受け付けている最中ですので,ご意見ご感想などをお待ちしています.
よろしくお願いします.
なお,Proposalの作成にあたっては@lestrratさんに大変なご助力を頂きました.ありがとうございます. (具体的に言うと,僕の書いた破滅的な英語もとい英語とも呼べない代物を牧さんに適切な形に翻訳し直し……というかもはや書き直して頂いた上に,内容に関しても多くの助言を頂きました)
コードレビューポエム
これはポエムです (It's just like a unko).
■
「なぜコードレビューをするのか」という問いに対する答えは様々だ.コードの品質を上げるため,コードレビュー自体が楽しいから,あるいはコードレビューやってる俺たちって恰好良いじゃん,などなど色々ある.
これらは全部正しいと思う.コードレビューをすればコードの品質が高くなる可能性は強まるだろうし,「コードレビューが楽しい」という感情がコードを書くための原動力になるのであればそれは良いだろうし (なぜならコードレビューをするにはレビュー対象たりえるコードが必要だ),「コードレビューやってる俺たちって恰好良いじゃん!」というのも結構だ.貴方がたは本当に恰好良いヨ!
さて,コードレビューという話題に必ずついて回る尤もらしい理由の1つである「コードの品質向上」について考えたい.
なぜコードレビューがコードの品質を上げるための手段としてここまで人気なのか.
例えばコードレビューではなく,書籍を読んでそこから得られた知見で品質を上げることは出来ないのか.或いは他のプロジェクトのソースコードを読んで,そこから学び,活かすことは出来ないのか.さてこれらは反語だ.多分可能だと思う.長い時間,極端な例だが1年かければ確実にその対象のコード (例えば1 issue分のコード) の品質を最高にほど近い水準まで持っていけると思う.
しかし期日の無いプロジェクトなど無い.仮に全ての開発メンバーが各々1つのissueに1年もかけてしまってはビジネスは破滅する.我々に要求されているのはスピード感だ.
つまりあけすけに言うと,「コードの品質を向上させるため」っていう大義名分は重要な接頭辞を省略していて,これを省略せずに言い換えると「短期間でコードの品質を向上させるため」になると思う.
我々はコードを書く時に思考する.いつだってこれが最善かどうか悩むし,不安になる.そのまま自問自答を繰り返しても良いが,そうしている間にも納期は陽気にやってくる.
そのように1人悶々とする時期も必要かもしれないが,やはり我々に求められているのはスピード感と最高のグルーヴだ.所属しているプロジェクトのドメインに詳しい仲間に質問して,意見を求めて,相談して,そして実装を始めたり洗練させたりしたほうが早く解決する可能性が高い.
つまり「最短距離で」なおかつ「高品質で」突っ走る為にコードレビューは必要なのだと思う.そしてそれがウケているから人気なのだとも思う.
従って,その最短距離を目指しているはずの「コードレビュー」で奇妙なところを指摘して,迂回させるのはまったく意味が無い.しっかり本質を見極め,そこに力を割かなければならない.コストを下げる為の活動なのに,逆にコストが上がってしまってはならない.
文字だけでコードレビューしてると (例えばGitHubのWeb UI上とかで) こういうことは起きがちで、そもそも文字ベースのコミュニケーションは話題が本筋から逸れた時に元に戻しにくい傾向にあると思う.変な議論が始まるとずっと変な議論を続けがちになるから良くない.そういうのを避けるためにも,毎回とは言わずとも,そこそこの頻度で実際に対面してコードレビューは行なったほうが良いと思う.
さて,最小のコストで高品質を求める皆さんならもうお察しでしょうが,最小のコストで高品質を獲得出来るならコードレビューをしなくても良い.例えば「1+1 = 2」みたいなコードに対してレビュー出来る事は少ないと思うので,こういうところにコードレビューのコストを割くべきではない *1.コードレビューをすることによって生じるコストと,そのコードレビューによって得られる利益とを比較検討しなければならないと思うけど,そこら辺難しいですよねという感じ.相談すべきか,相談せざるべきか,という問題になってしまう.まあ悩むくらいなら誰かに相談すれば良いと思うんですが.
その辺のバランス感覚を養いたいものです.
*1:数学の怖い話はよそでやってくれ!
App::GitHubWebhooks2Ikachanが出た
長い名前だ!!! そしてマニアック.
https://metacpan.org/release/App-GitHubWebhooks2Ikachan
https://github.com/moznion/App-GitHubWebhooks2Ikachan
これは何
GitHubのWebhooksを受け取って,いい感じにしてIkachanに投げる君です.
現状,issues
,pull_request
,issue_comment
,push
の各イベントに対応しています.
雰囲気としてはこんな感じの通知がIRCに飛ぶ.
[issue opened] This is new issue (@moznion) https://github.com/moznion/sandbox/issues/13
[comment (#13)] foobar (@moznion) https://github.com/moznion/sandbox/issues/13#issuecomment-37093289
[push to master] Commit1 (@moznion) https://github.com/moznion/sandbox/commit/b4da12df1bc19d2b20d7ab8a11fe9a4413ddf509
[push to master] Commit2 (@moznion) https://github.com/moznion/sandbox/commit/e2e64cea713dbfb574f1ace80a4be6c55f98433d
[pull request opened] New Pull Request (@moznion) https://github.com/moznion/sandbox/pull/15
GitHubのWebhooksの詳細については以下などを参照いただくと良いでしょう.
http://developer.github.com/webhooks/
http://developer.github.com/v3/activity/events/types/
使い方
まず何はなくともサーバを立ち上げます.
CPAN経由でこのアプリケーションをインストールするとgithubwebhooks2ikachan
というコマンドがインストールされるのでそれを使って以下のように立ち上げるのが良いでしょう.
$ githubwebhooks2ikachan --ikachan_url=http://your-ikachan-server.com/notice --port=12345
この時,ikachan_urlは必須です.portはオプショナルです.デフォルトだと5555番ポートが使われます.
次にGitHubのWebhooksを登録します.
リポジトリの設定のところから“Webhooks & Services”を開いてWebhooksの設定を行います.
「どのイベントの時にWebhook送ってほしい?」って部分は“Send me everything”にしておけば良いと思います.
肝心のPayload URL
は以下のようになるでしょう.
http://your-githubwebhooks2ikachan-server.com/${path}?subscribe=issues,pull_request&issues=opened,closed&pull_request=opened
${path}
の部分は通知を送りたいIRCのチャンネル名になります.
つまり,http://your-githubwebhooks2ikachan-server.com/%23foobarとか書いておくと,#foobarにメッセージが飛びます.
クエリパラメータのsubscribe
の部分は通知を飛ばして欲しいイベント名をコンマセパレ―テッドで指定できます.
例えば,subscribe=issues,pull_request
と書くと,issues
イベントとpull_request
イベントだけ通知するようになります.
このパラメータを省略した場合は,対応しているイベントすべて *1 のWebhookが飛んできた時に通知します.
issues
とpull_request
パラメータは通知を飛ばして欲しいアクション名をコンマセパレ―テッドで指定できます.
例えば,issues=open,close
のように書くと,issueがopenされた時とcloseされた時にだけ通知を飛ばすようになります.
パラメータを省略した場合はすべてのアクションに対して通知します.
いろいろ
本当はissuesやpull_requestとかだけではなく任意のイベントを差し込めたり,NotifierをIkachanだけではなくて他のものに差し替えられたり,出力フォーマットを好みの形に変更できたりする予定だったんですが,複雑性が増す上に利用側に結構な量のconfigを書いてもらわなければならなくなったので,今の形に落ち着きました.
「このイベントが取れないとは何事だ!」みたいなお叱り等ございましたら,Issueなどに登録していただけると対応しますのでよろしくお願いします.
*1:つまりissues
,pull_request
,issue_comment
,push
「システム環境設定」でアイコンがグレーアウトしてる項目について設定したい
Mac OS Xの話です.
権限の都合上,「システム環境設定」のアイコンがグレーアウトしていて,その項目に関して設定出来ないことがあります.こんな感じ.
この場合だと,「セキュリティとプライバシー」と「共有」がグレーアウトしていて設定が出来ません.
どうするか
以下のコマンドを実行して,NSPrefPaneGroups.xml
ファイルを移動します (実際は削除でも良いんですが).
$ sudo mv /Applications/System\ Preferences.app/Contents/Resources/NSPrefPaneGroups.xml /Applications/System\ Preferences.app/Contents/Resources/NSPrefPaneGroups.xml.orig
すると,「システム環境設定」が以下のように変化します.
オゥ,なんてこった!!! アイコンが全部なく無くなっちまった!!!
しかしご心配なく.上のツールバーの「表示」を選ぶと……
設定項目がズラっと表示されます.そしてなんと,グレーアウトしていたはずの項目が設定できるようになっている!
便利!!!!!!!
あるいは
$ sudo cp -R /Applications/System\ Preferences.app ./Ura\ System\ Preferences.app $ sudo rm Ura\ System\ Preferences.app/Contents/Resources/NSPrefPaneGroups.xml $ open ./Ura\ System\ Preferences.app/
などとしてやって,System Preferences.app
をコピーして,そのコピーしたappからNSPrefPaneGroups.xml
を取り除いてやると同様の効果が得られます.
とは言え
セキュリティ等の観点から設定できないようにグレーアウトさせているケースが多いと思うので,悪用は厳禁です.
OAuth2のAccess Tokenを取るためだけのサーバー書いた
唐突にGitHubのAPIが使いたくなって,その為にはOAuth2で認証を通さなければ駄目で,作りたいアプリケーションにはAccess Tokenをソース中にベタ書きしちゃえばいいかなー(!)という雰囲気で,結果的にどういうことかというとOAuth2の認証通してAccess Tokenだけとれればオッケーっていうのが欲しかったんですね.
「そういうことをするにはサーバーを書け!」みたいな感じだったので適当に書いた.
https://github.com/moznion/OAuth2TokenVendingServer
設定ファイル書いてサーバー立ち上げてアクセスしてAuthenticateすればAccess Tokenがゲロッと表示される,というただただそれだけの代物です.多分GitHub以外のOAuth2認証でも使えると思います.これで何度も何度も書きなおさなくて済む気がしていますがどうでしょうか.
なにやら適当な解説ですが適当なサーバーなので適当でも良いかと思った次第.
ところで作りたいアプリケーションについては完全に忘れてしまったので誰かご存知でしたら教えてください.現場からは以上です.
[追記]
OAuth1版も出ました.
https://github.com/moznion/OAuth1TokenVendingServer
最初,1と2は分割しないで,1つのサーバーでどちらも使えるようにしようと思ったんですが,OAuth1とOAuth2ではもろもろの用語が違ったりして,これらを統一的に扱おうとすると混乱を招きそうだったので別居させました.
トークンが欲しくなる場面はそれほど多くはないかもしれませんが,ご利用ください.
tmux 1.9系でもcurrent pathの情報を引き継いでnew-windowやsplit-windowしたい
去る2014年2月22日にtmux 1.9がリリースされたので勇んでアップデートしたところ,1.9からはdefault-path
オプションが削除されており,またそれが原因かどうかは定かではありませんが *1,new-window
やsplit-window
するとcurrent pathの情報を引き継いで *2 くれなくなってめっちゃ不便!!!! ってなって,「これもう1.9にアップデートしなくても良くね??? CHANGES見てもこれといった変更ないし……」という心意気に一時はなったんですが,僕みたいな糞ミーハーはやっぱり新しいものを使いたいのでちょっと調べてみました.
結論
bind '"' split-window -vc "#{pane_current_path}" bind '%' split-window -hc "#{pane_current_path}" bind 'c' new-window -c "#{pane_current_path}"
このように-c
オプションを付けてやって,その後ろにsplit後あるいはnew後に移動して欲しいディレクトリパスを指定すると良いです.
なお,このコード例に書かれている#{pane_current_path}
はcurrent pathを表しています.大体の場合はコピペすると動く気がします.
結論2
@mitukiii `bind " split-window -vc "#{pane_current_path}"`とかやると上手く行くっぽい事を報告します
— 人間乱数生成器 (@moznion) 2014, 3月 2
良かった、1.9a使っても行きていける
— 人間乱数生成器 (@moznion) 2014, 3月 2
@moznion よく見たら CHANGES にちゃんと書いてあった死にたい https://t.co/PZwAEujj4l
— ʞɐznʎɐ ʇɐʞǝsɥıɯɐ (@mitukiii) 2014, 3月 2
@mitukiii めっちゃ厳しい気持ちです
— 人間乱数生成器 (@moznion) 2014, 3月 2
CHANGESはちゃんと読もう!