eyecatch
Sun, Aug 21, 2016

オープンソースプロジェクトのすゝめ

人は生まれながらにして貴賤の別なく、ただオープンソースプロジェクトを勤めて物事をよく知る者が貴人となるなり。 昔、偉い人がそんな感じのことを言っていたような。 私がGitHubで開発しているライブラリ、Pcap4J のスターの数がつい先日 200 に達したのを記念して、これまでどんな活動をしてきたか、この活動によって何を得たかなどについて書きたい。 願わくは、この記事に触発されてオープンソースプロジェクトを始める人のあらんことを。 Pcap4Jとは? Pcap4Jは、パケットキャプチャとパケット解析をするJavaのライブラリ。 ニッチ。 ただ最近になってビッグデータ解析技術が発達し、大量のパケットをリアルタイムで解析してシステムや運用にフィードバックするというのが現実的になってきたので、パケットキャプチャへの注目が高まってきている雰囲気がある。 こういう分野ではJavaがまだかなり人気なのもあってワンチャンある。 パケットキャプチャの部分は pcap のラッパ。 パケット解析の部分は割とプラガブルで、外からプロトコル追加などのカスタマイズができるはできるんだけど、作りのせいなのかJavaなせいなのか解析器を書くのが結構つらい。 競合は jpcap や jNetPcap など。 Google.comでjava packet captureと検索するとだいたいjpcap、Pcap4J、jNetPcapの順で表示される。 打倒jpcap。 数字で見るPcap4Jプロジェクト Pcap4Jリポジトリの一番古いコミットは 2011/12/18。 東日本大震災後の節電施策として実施された休日シフト中にコーディングしていた覚えがあるので、多分2011年夏くらいから開発していたんだけど、とりあえずこの最古のコミットをプロジェクトの開始とすると、スターが200になった 2016/8/11 まで 1698日 かかったことになる。 約 0.118個/日。遅い… コミット数は 559個。ほとんどが自前のコミット。 プロジェクト成長過程の動画を Gource というツールで生成してみたが、一人でかけずりまわっているのがよく分かる。 コミット頻度は約 0.33個/日 で、だいたい3日に1コミット。 思っていたより多いけど、胸張れるほどの頻度ではない。 リリースは 17個 で、約 0.30個/月。少ない… Issuesが 52個、Pull requestsが 16個。 自分ではIssuesもPull requestsもあまり作らないので、ほとんどが他人からのもの。 ちゃんとチケット駆動にしてトレーサビリティを確保しておくべきだったと後悔している。 けど面倒だし今更なので今後も適当にコミットしちゃう。 あとはWatchが 28人、Forkが 66個、コントリビュータが 7人。 スター200ってどうなの? jQueryやReactなんてスター40000超えてるし、JavaならSpring Frameworkも10000に達しようとしている。200なんて全然大したことなくない? と言う声が聞こえるようだが、そんな知らない人を探すのが難しいようなプロジェクトと比べてはいけない。 スター200以上のプロジェクトは割合でみるととても少ない。 現在GitHubがホストしてる全プロジェクトは 14,308,407 個。 Javaプロジェクトはその内二番目に大きい割合を占めていて 1,501,840
eyecatch
Thu, Aug 18, 2016

GitHub Pagesの新機能、ソース設定が地味にいい

今日、よりシンプルにGitHub Pagesを使えるようになったというアナウンスがあり、ソース設定という新機能が追加されていたので、さっそく試してみた話。 GitHub Pagesの新機能: ソース設定 GitHub PagesにはUser Pages、Organization Pages、Project Pagesの三種類があるが、ソース設定が使えるのはProject Pages、つまりGitHubリポジトリごとに使えてusername.github.io/projectnameのようなURLのやつだけ。 今まではProject Pagesで公開するサイトのソースはgh-pagesという名のブランチに置く必要があったが、ソース設定によりmasterブランチのルートに置いたりmasterブランチの/docsフォルダに置いたりもできるようになった。 ソース設定の使い道 Pcap4Jのホームページのソースをmasterブランチの/docsフォルダに置く設定にしたら捗った。 Pcap4JのホームページはHugoで作っていて、以前は、Hugoのソースをpcap4j-hpリポジトリのmasterブランチに置き、gh-pagesブランチを作ってそこにHugoのビルド成果物(=ホームページのソース)を入れていた。 ローカルPCでは、masterをcloneして、そこからgit worktreeでgh-pagesを別のフォルダにチェックアウトしておいてあり、Hugoのビルドオプションでgh-pagesのフォルダにビルド成果物を出力するようにしていた。 これだと、ホームページを修正したい場合、まずmasterでHugoソースを修正してgit add/commit/push、次いでビルドしてgh-pagesフォルダに移動してgit add/commit/push、というように、二度手間で面倒だった。 Hugoのビルド成果物をmasterブランチの/docsフォルダに置けるようにできれば、git add/commit/pushはビルド後にmasterに対して一回だけやれば済むようになる。 gh-pagesからmasterブランチの/docsフォルダへの移行 GitHubのヘルプを参考にしつつ、 ローカルPCで、masterの作業ディレクトリのルートにdocsというフォルダを作り、gh-pagesのフォルダの中身を全てそこに移動。 masterのdocsをgit add/commit/push。 GitHubのpcap4j-hpリポジトリのページに行き、SettingsタブのGitHub PagesセクションのSourceをgh-pages branchからmaster branch /docs folderに変えてSaveボタンをクリック。 実にこれだけ。 カスタムドメインにしていてもこれだけ。簡単。ダウンタイムもなし。 あとはローカルPCのgh-pagesの作業ディレクトリを削除したり、gh-pagesブランチを削除したり。
eyecatch
Fri, Aug 28, 2015

GitHub Pagesでブログ立ち上げ - Hugoを使う

GitHub Pagesでブログ立ち上げ - Jekyllのためのツールの続き。 前回は、GitHub Pagesで公開するブログサイトを構築するのに、JekyllとJekyll関連ツールを使おうと四苦八苦したが、結局Jekyllに見切りをつけ、Hugoを使うことに決めた。 Hugoとは Hugoは、国内では2014年末くらいから盛り上がってきているブログサイト構築ツール。 そのホームページによると、ウェブサイトフレームワークで、静的サイトジェネレータとのこと。 フレームワークと名乗ってはいるが、その正体は、Markdownで書かれた記事を元にブログサイトのソースを生成するコンテントビルド機能と、記事作成(など)を支援するユーティリティ機能を持ったコマンドラインツール。 また、静的サイトジェネレータというのは、静的なサイトを生成するという意味ではなく、静的にサイトを生成するという意味。もっと言えば、WordPressとかがアクセス時にビルドが走るのに対し、Hugoを使った場合は事前にビルド済みのものをサーバにアップロードすることになる、ということ。らしい。WordPressは使ったことがないのでよく知らないが、Hugoのホームページにそう書いてある。 つまり、Hugoは静的なサイトだけを扱うツールってわけではないので、JavaScriptとかを駆使して動的でインタラクティブなページを作ってもいいはず。 Hugoのインストール インストールガイドに従ってHugoをインストールする。 HugoのGitHub ReleasesからWindows用バイナリをダウンロード。このときはバージョン0.14が最新だったので、hugo_0.14_windows_amd64.zipをダウンロードした。 このzipの中身はhugo_0.14_windows_amd64.exeというバイナリ一つとLICENSE.mdとREADME.mdだけ。 このhugo_0.14_windows_amd64.exeがHugoのすべてなので、これを適当な場所において実行できるようにしとけばよい。 今回は、hugo.batというファイルに以下の内容を書き、PATHの通ったフォルダにいれた。 @echo off C:\Users\Kaito\Desktop\tool\hugo_0.14_windows_amd64\hugo_0.14_windows_amd64.exe %* これで、どこからでもhugo [arguments]と打てばHugoコマンドが実行できる。 Hugoのシンタックスハイライト ドキュメントによると、Hugoではシンタックスハイライトを実現する方法を以下の2つから選べる。 サーバサイド: Hugoでのブログサイト生成時にハイライトしておく方法。 クライアントサイド: クライアントがブログを読み込んだ時にJavaScriptでハイライトする方法。 前者の方が当然クライアントの負荷が軽くなるが、Pygmentsのインストールが必要だったりめんどくさそうなので後者にする。(PygmentsはJekyllのときにすでに入れたけど…) クライアントサイドでやるのもいくつかやり方があるが、例えばHighlight.jsを使うなら以下をHTMLヘッダに加えるだけでいい。 <link rel="stylesheet" href="https://yandex.st/highlightjs/8.0/styles/default.min.css"> <script src="https://yandex.st/highlightjs/8.0/highlight.min.js"></script> <script>hljs.initHighlightingOnLoad();</script> このdefault.min.cssの部分を変えると色々なスタイルが選べる。 このブログではZenburnを使うことにした。 Hugo味見 Hugoコマンドリファレンスを見つつ、Hugoの味見をする。 サイトのひな形を作るコマンドはhugo new site [path]。hugo new site blogを実行して、blogという名のフォルダにサイトの初期ソースを生成。blogの部分はファイルもフォルダも存在しないパスを指定する。 この時点で、blogフォルダ内には以下のものが入っている。 archetypes: 新規記事作成時に自動で挿入されるFront Matter (後述)のカスタマイズをするためのファイルを置くフォルダ。 content: ブログのコンテンツ(記事など)を置くフォルダ。 data: サイト生成時に使うデータを置くフォルダ。 layouts: サイトのレイアウトを定義するファイルを置くフォルダ。 static: CSSとかJavaScriptとか画像とかのファイルを置くフォルダ。 config.toml: 設定ファイル。これはTOMLだが、YAMLかJSONでもいい。 記事を作るコマンドはhugo new [path]。blogフォルダにcdして、二つ記事を作ってみる。 hugo new about.md hugo new post/first_post.md blog\content\about.mdとblog\content\post\first_post.mdが生成された。 これらには、Front Matterという、記事のメタ情報が自動で書き込まれる。 デフォルトで書き込まれるのは、日付 (date)、ドラフトフラグ (draft)、タイトル (title)だけだが、 Archetypesという機能でカスタマイズできる。 が、今はやらない。 about.mdとfirst_post.mdには適当に記事の内容を書いておく。 次にテーマを設定する。テーマを使えば、自分でレイアウトを書く必要がない。 テーマはHugo Themesにリストされていて、ひとつひとつ選んでインストールもできるけど、今回は全部いっぺんにインストールして色々見てみる。blogフォルダ内で以下を実行すると、blog\themesに全テーマがインストールされる。 git clone --recursive https://github.com/spf13/hugoThemes.git themes これで、以下のコマンドを実行すると、サイトがビルドされ、サーバが起動し、ブラウザで確認できる。 hugo server -t angels-ladder -D -w -tでテーマを指定している。指定するのはblog\themes内のフォルダ名。-Dはドラフト記事をビルドしたいときにつけるオプション。さっき作ったabout.mdとfirst_post.mdは、そのFront Matterのdraftがtrueになっていて、つまりドラフトなので、-Dを付けないとビルドされない。-wはLiveReloadを有効にするフラグで、付けておくとソースを修正したら自動でリビルドとブラウザのリロードが実行される。(変更を監視されるのはサブフォルダ内だけ。config.tomlの変更は無視される。) サーバにはhttp://localhost:1313/でアクセスできる。今回指定したテーマangels-ladderだと、トップページにfirst_post.mdの記事へのリンクがあり、その内容を確認できる。about.mdの方はリンクはなく、直接http://localhost:1313/about/アクセスしないと見れない。この辺りはテーマ(と設定?)によって異なるのかな。 まあabout.mdは試しに作ってみただけなので消しておく。 hugo serverの-tに与える値を変えれば簡単にテーマを切り替えられるので、いろいろ見てみる。 以上で味見終わり。 テーマの選定 - Robust Hugo Themesにあるテーマはどれもあまりしっくりこなかった。 もう自分で作ろうかと思っていたところ、Robustというテーマを見つけた。 こんな感じのページができる。いい。これを使うことにする。 blogフォルダ内で、いったんthemesを消してから以下を実行してRobustをインストール。 > git init .
eyecatch
Tue, Aug 25, 2015

GitHub Pagesでブログ立ち上げ - Jekyllのためのツール

GitHub Pagesでブログ立ち上げ - GitHub PagesとJekyllの続き。 前回は、GitHub PagesとJekyllでブログを始めることにして、Jekyllのセットアップに四苦八苦した。 Jekyllがだいたいセットアップできたところで、どんなサイトデザインにしようか考え始めた。 調べたところ、生のJekyllを使うよりも簡単に見栄えのいいサイトを作れる方法がある模様。 Octopress もっとも有名なのはOctopress。 ホームページの説明によると、「Octopress is a framework designed for Jekyll, the static blogging engine powering Github Pages」とのこと。 フレームワークと呼ぶのはちょっと大げさな気がする。 まあ見たところ、Jekyllをサイト生成エンジンとした、ブログサイト構築、ブログエントリ作成、ブログサイトデプロイなどを簡易化するツール。 広く使われていて情報が豊富だし、テーマを選んでエントリの内容をMarkdownで書くだけでかっこいいサイトが作れる。バージョンは2系が主に使われているやつで、3系がβ状態。 血迷って3系に手を出してみる。GitHubにあるREADMEを見ながらWindows 7上にインストールして、適当なサイトを作ろうとするもjekyll buildでエラー。さすがにWindowsじゃだめかと思い、CentOS 7のVMを立ち上げてそこでやってみるもまたjekyll buildでエラー。 心折れかけながらドキュメントなど見ていたら、多くのプラグインがまだ開発中で、3系は基本的な機能しか動かなそうなことが発覚。素直に2系にすることに。 2系は成熟しているし情報が沢山あるので、順調にインストールとテストサイト作成に成功したあたりで、不審な情報を発見した。 Jekyllのドキュメントによると、GitHub Pagesではセキュリティ対策のためにJekyll をセーフモードで実行するため、カスタムプラグインが無効になるとのこと。 Octopressが生成したJekyllソースをGitHub Pagesに上げたらビルドして公開してくれると思っていたけど、OctopressはJekyllのプラグイン機能をもりもり利用しているようなので、上手くいかないようだ。 つまりOctopressをGitHub Pages上のサイトに使うとしたら、結局ビルド成果物をアップしないといけなくなる。JekyllのソースだけをGitHubで管理するように出来たらいいと思っていたが当てが外れた。 Jekyll-Bootstrap Octopressを使うモチベーションが下がり、他のを探したところ、Jekyll-Bootstrapというのを見つけた。 Jekyll-BootstrapはJekyllのソースそのもので、面倒な部分は既にできてるので、ユーザはテンプレートを使って記事の内容を書くだけでいいよ、というもの。テーマ機能と、記事作成作業をRakeで簡易化するためのRakefile付き。 すばらしいことに、「JekyllのソースだけをGitHubで管理するように出来たらいい」という需要に応えることを目指して作られていて、Jekyll-Bootstrapをベースに作ったJekyllソースはGitHub Pages上のJekyllでビルド可能。 まさに求めていたものと心躍った。 が、プロジェクトページを見るにあまり活発に開発が進んでない模様。 廃れ行きそうなツールを使うのもなぁ… 結論 Jekyll-Bootstrapを使うのは気が進まない。Octopressを使うとビルド成果物をアップしないといけない。 どうせビルド成果物を上げるのなら、Jekyllにこだわる必要はないか、ということで、去年末くらいから盛り上がってきているHugoにすることに。Hugoについてはまた別のエントリで書く。