とりあえず動作するけど、もうちょっとうまい書き方はないかなあ。
Scala練習 – 文字列をサロゲートペアを考慮した1文字ずつに分割する
Forkwell.comリニューアルキャンペーンでMacBook Proをいただきました
エンジニア向けのポートフォリオサイトであるforkwell.comさんのリニューアルキャンペーンにて、当選し、MacBook Pro Retina 15インチ
本当にうれしいです！
これで、いっぱい開発しよう！
Source: ソースのAnalyzerをScalaで実装してみる
Source:ならびに、そのベースであるOpenGrokのソース解析はJFlexで作られています。また、ソースからのタグの取得にExuberant Ctagsが使われています。解析が二段階になっているのは効率がわるいのと、JFlexで作られたソースのデバッグがやや面倒なこと、さらにScalaの勉強のためにAnalyzerをScalaで実装してみることにしました。ひとまずこんなかんじ。
実行結果は
(2,KeywordComment(* test
))
(6,KeywordDefPackage(List(org, watermint, sourcecolon, indexer)))
(7,KeywordRefSymbol(List(org, watermint, sourcecolon, analyzer)))
(8,KeywordRefSymbol(List(org, watermint, sourcecolon, Main)))
こういう風にソースの中の検索キーワードにしたいものだけがなんとか取り出せました。
Source: Release 3
ソースコード検索として改良を続けているSource: (ソースコロン)ですが、いくつか問題を修正したのでRelease 3としてタグをうちました。
今回のリリースではソースコードに含まれる日本語のコメントなどが、UTF-8でなければうまく表示されなかったのが、ICU4Jによる自動判定によりEUC-JPやShift-JISなどの場合でも表示できるようになりました。あくまでも自動判定のため、特に日本語文字列のサンプルテキストファイル中にが少ない場合には判定に失敗してうまく表示できない場合がありますが、かなりの文字化けは救えるようになりました。
Source: サーバサイドでgoogle-code-prettifyを適用する
Source: Release 2ではgoogle-code-prettifyを使ってソースコードの整形をするようにしましたが、これだと長いソースコードを表示するときには若干待たされます。
そこで、サーバサイドでインデックスをする段階であらかじめソースコードを整形済みのHTMLにしておき、表示を高速化できないかという実験をしてみました。いくつか候補を探した結果、
を参考にenv.jsを使って、サーバサイドでgoogle-code-prettifyを適用してみました。
env.jsとgoogle-code-prettifyを読み込み、エスケープやパラメータの追加などを考慮してソースコードをJSONで渡します。
JavaScript側でbody以下にcodeタグにprettifyのクラスを付与してprettyPrint()を実行します。
無事prettifyによるタグが付与されました。Indexerにちゃんと組み込むのは意外と面倒なので時間はかかりそうですが、なかなか良さそうなのでRelease 3では組み込みしてみようと思います。
Source: Release 2
Source: の開発コンセプトとアーキテクチャを考えるで書いた通り、Source: はすこしアーキテクチャをかえようと思っていましたが、最近、今使っているOpenGrokの調子が悪く必要に迫られてOpenGrokベースのr1をもう少し整理してSource: Release 2としてリリースタグをうちました。
OpenGrokと比べて、Twitter Bootstrapを適用しただけでなく、すこしUIを変えています。検索とコンテンツを左右のペインに分割し、検索やナビゲーションといった情報は左ペインに配置することにしました。特にナビゲーションは、Navigationというメニューをクリックしないと出てこない機能で、便利なのにわかりにくいこともあってナビゲーションができるときには常に左ペインに表示するようにしました。
ナビゲーションで表示される、Class、Package、Methodといった情報はExcuberant Ctagsによるタグ情報を表示しています。Source: ではExcuberant Ctagsは必須ではありませんが、システムのパスに通っていれば自動的に利用してこのような追加の情報を表示するようになっています。
ソースコードの表示はOpenGrok独自のスタイルから、google-code-prettifyを使うように変更しました。
内部的には、とくにOpenGrokのscriptletだらけのひどいJSPをずいぶん書き換えましたのでUI周りの変更はかなりやりやすくなりました。まだまだレガシーな感じのコードはいっぱい残っているのですが、そこはおいおい修正していこうと思います。
PlantUML4Markdown
PlantUMLというテキスト記法からシーケンス図をはじめとしてUMLの図をかけるツールがあります。Markdown形式のドキュメントにこのマークアップを書いて、図がかけたら便利だなと思ってそういうツールがないか探してみましたが意外とすぐ見つからなかったので作りました。
Drobo 5N, 導入から2週間
NASのDroboシリーズのうちDrobo 5N
最後の2TBディスクを差し込んだ次の日、いきなりそのディスクが認識しなくなり復旧モードに・・・。無事Droboのデータ保護プログラムが動き、特に問題はありませんでしたが導入直後だったのでヒヤヒヤしました。
Droboへのコピー、Droboからのコピーはやはり1回のコピーが数十万ファイルとか、数百ギガバイトレベルになると普通にFinderなどからコピーしたり、cp -r などコマンドでコピーすると途中で失敗することがあり、高い信頼性を持ってコピーするにはやはりrsyncのようなネットワークを前提としていろんな障害を前提として設計されたコマンドを使った方がよいということもわかってきました。
SoftBank PANTONE 5, 107SH
docomoのP-01Cというケータイから乗り換えました。
大きさが、iPhone 3GSとほぼ同じ、おサイフケータイがついているという点で選びました。最近のスマートフォンは大きすぎて持ち運び大変そう。また、Androidならば最低でも4.0以上であってほしいのでそういった条件をつけて選びました。
Android 4.0以上、4インチ未満のものに限定すると選択肢は次の通りでした。
- SoftBank Honey Bee 201K – 3.7インチ
- SoftBank PANTONE 5 107SH – 3.7インチ
探し方が悪くなければdocomo、au、emobileにはその条件のものはありませんでした。Honey Bee 201Kもまあまあ良かったのですが、4G回線対応のため月額基本料が高くなるので消去法でPANTONE 5に決まりました。
Drobo 5N
I-O DATA HDC2-U2.0
しかしながら、いよいよ3TBのハードディスクをつかっても容量が厳しくなってきたのと、手動でコピーだとRAID 1相当になって空間効率が良くないこともあり、もう一度トライする気持ちでNASを導入しました。今回は、最近名前をよく聞くようになったDroboシリーズのうちDrobo 5N
Droboシリーズは、容量の異なるHDDをさしても勝手に認識してよしなに冗長性を保ったまま容量を拡張してくれるので運用はとても簡単です。静音性、バックアップ電源、mSATA SSDを使ったパフォーマンス向上など基本的な信頼性と性能の高さを重視しました。本当はこれまでの故障の経験から製品保証が長いこと重視しようとしていました。米国のDroboでは2年保証のようなのですが、販売元のPGダイレクトに確認したところ日本では1年保証となるとのことでここは故障しないことを祈りつつ運用することにしようと思っています。