WX310K、いわゆる京ポン2を持って以降、出先でのWeb閲覧がお手軽にできるようになってからNexus5を持つ現在へと至っていますが、スマホ・タブレット時代になって相当リッチなWebアプリも動かせるようになりました。昔から現在に至るまで利用しているWebアプリケーションについて書いてみようと思います。 ソースコード閲覧 GNU Global このソフトはctagsの強化版といった感じのソフトウェアですが、ハイパーリンクでのクロスリファレンスを実現した静的HTMLも出力することができます。JavaScriptなどを使わないシンプルな出力なので、非力なWX310Kでもそれなりに利用できていました。今でも使っています。 gonzui 主にRubyで書かれたソースコード特化型検索エンジンです。残念ながら2005年を最後に更新がありません。かつては利用していました。 milkode 同じくRubyで書かれたソースコード検索エンジンです。開発は活発で、対応している言語もgonzuiより多いので、現在はこちらを使っています。gonzuiが独自データベースであったのに対し、milkodeはバックエンドにGroongaを使っています。 Pootle(翻訳) Pythonで書かれたWebアプリとして動作する翻訳ツールです。かなりモダンな造りでJavaScriptをガッツリ使っています。スタンダードなpo形式も扱えるので、役に立っています。 ownCloud(オンラインストレージ) PHPで書かれたオンラインストレージです。Linux, Windows, Android, iOS等のクライアントが用意されていますが、WebDAVとしても動作します。Webアプリとしても動きます。 サーバーサイドでAESを使った暗号化ができたり、サードパーティWebアプリがいろいろとあったりします。RSSリーダーもあるので、もしFeedlyがなくなってしまったらそれを使ってみようと考えています。 その他 gitlabやredmineも用意したのですが、これらはいまいち活用できていません。以前はWebでIMAPを扱えるIrohaMailも入れていたのですが、使い勝手がいまいちで消してしまいました。今時であればスマートフォンのIMAPクライアントで十分でしょう。
積みハード2014
昨年かっただけで触っていないハードウェアやデジタルガジェットがいくつもあるので、反省とともに記録しておきます。 Cloud Flash PQI Air Cardと同じような製品で、本体はmicroSDカードスロットとWiFi APを持ったSDカードです。デジカメに差して、ワイヤレスで画像などが転送できるというものですが、中身はarmベースのLinuxが入っています。 ちょっといじればtelnetできるようになったり、さらにはPQIのファームウェアを書きこんでPQI Air Cardと全く同じものにすることも可能だそうです(Linux搭載無線LAN内蔵SDカードアダプタCloudFlashが値下げで1,980円!めちゃくちゃ魅力的だし間違った使い方も可能)。 Leap Motion 両手の10本指をトラッキング可能なデバイスです。Linux, Windows, Macのデバイスドライバがあります。インターフェースとしてwebsocketサーバと提供しており、アクセスすれば情報がjsonで取得できるので、割と簡単にアプリケーションが書けます。SDKも各種用意されています。 一応こいつは新年にようやく開封して、Windows上ではある程度使えるようにはしました。Blenderのプラグインをいれることによって、3DモデリングがLeap Motionである程度行えるという、なかなか未来感のあるデバイスです。 Leap MotionとBlenderについては改めて記事にしようと思っています。 USB BB弾ランチャー かつてUSBミサイルランチャーというものが流行ったことがあるのですが、こちらはBB弾を発射できるものです。上海問屋で安売り(1980円)していた時に買いました。しかし箱から出してすらいません… 多分http://www.donya.jp/item/25694.htmlこれと同じものじゃないかと思うのですが、カメラはついてたかどうかも定かでないです。 他にもあるような気がするのですが、思い出すか見つけ出すかしたらちゃんと触ろうと思います。
Google::API::OAuth2::Clientのトークン情報をシリアライズする
先日書いた「Google::API::Clientを使う(perl)」の続きです。前回示したコードでは毎回認証してアクセスコードを入力しなければいけないので、それを回避するためにjsonで保存するためのコード例を示してみます。 トークンの保存 トークンの読み込み Data::SerializerでGoogle::API::OAuth2::Clientを丸ごとシリアライズしてみる、ということもやってみたのですが、不完全のようでシリアライズ時に警告が出たり、デシリアライズしたオブジェクトを使った際、最後にsegfaultを起こしたりします。 あとは、new_from_client_secretsというメソッドでjsonファイル上に記録されたauth_uri, token_uri, client_id, client_secretを読み込んで新しいオブジェクトを作成するものも用意されていますが、token_objについては考慮されていません。ファイル外部にclient_id等を記録しておける点が良い、ぐらいのものです。 もうちょっと永続化に関する手続きも簡略化されているとうれしいところです。
Internet ArchiveとDMCA改定
主にWebのアーカイブ(wayback machine)で有名なInternet Archiveが、MS-DOS用のゲームをブラウザ上でプレイできるよう公開した、というニュースがありました。 ねとらぼの記事(MS-DOSのゲーム約2400本がブラウザでプレイ可能に 海外サイト「InternetArchive」が公開)ではフェアユースの扱いという解説がありましたが、事態はもう少し複雑のようです。 インターネットアーカイブがMS-DOSゲーム2,400作品をブラウザ/Steamで提供 http://t.co/iGookjbMjS NamcoもWofensteinもアダルトもあって見切れん。デジタルミレニアム著作権法で公共図書館が例外になってよかった — Shinji R. Yamane (@shinjiyamane) 2015, 1月 6 Internet Archive、DMCAの改正を歓迎という記事で、Internet Archiveの行っていたソフトウェア、ビデオゲームのアーカイブが合法になったことについて触れています。 本家の声明Internet Archive Helps Secure Exemption To The Digital Millennium Copyright Act によると、「図書館のような公的機関に限って、もはや動作させることが困難な古い記録メディアや再生機器が必要な場合には、コピープロテクトなどを解除してアーカイブすることがゆるされる」という改正がなされたように読めます。Internet Archiveはアメリカの非営利公益法人であり、この対象となります。形体としては「インターネット図書館」と呼べるものです。 提供手段はWebブラウザ上での再生で、JSMESSというJavaScript実装のエミュレーターを利用しています。つまり誰でもゲームがプレイできる状態にあるわけですが、この点について法的にどうなのかという疑問を後藤さんがされていました。 @knok 収集することとそれを不特定多数に配布することとは直接は関係のない話のはずなので… — 後藤 浩昭 / GORRY (@gorry5) 2015, 1月 7 単純にコピーを配布する、という話であれば確かに問題があると思います。とはいえ、DMCAは先頭のDがデジタルであり、YouTubeのようなWeb上での配付に当たらない公開についての取り決めであったとなんとなく記憶していたので、改めて原文を確認してみました。 @gorry5 DMCAは電子データに関する取り決めなので、”webcasting”について明確に言及しているようです。videogameをブラウザで提供するのがwebcastingの範囲と判断されるのであれば合法となりそうです http://t.co/mDT5yiY8GS — NOKUBI Takatsugu野首貴嗣 (@knok) 2015, 1月 7 原文(pdf)には”webcasting”という表現がありました。Wikipediaの解説によると”Webcasting is… Continue reading Internet ArchiveとDMCA改定
Google::API::Clientを使う(perl)
ここのところいろいろな言語でGoogle APIをたたいてみています。PerlのGoogle::API::Clientを使ってみたのですが、ドキュメントがいまいち整備されていなかったので、実際にGmail APIをたたくサンプルを書いてみました。大まかな作りはruby, pythonのライブラリとあまり変わりありません。 OAuth2認証部分 $auth->authrorize_uriはresponce_type=codeなURLを生成します。上記コードで画面上に表示されたURLに接続・承認を行い、ブラウザ上に表示されたアクセスコードをexchangeメソッドの引数に渡します。これで認証は完了します。 client_secrets.jsonファイルからオブジェクトを生成するnew_from_client_secretsメソッドもありますが、jsonファイルにシリアライズするメソッドは用意されていないようです。 サービスの構築とメソッドの実行 ポイントは以下です。 client->buildでAPIとバージョンを指定 どんなメソッドがあるかはAPIs Explorerで確認 bodyは連想配列で記述(jsonにマッピングされる) 認証情報はexecuteの引数auth_driverに指定する リフレッシュはGoogle::API::Methods側でよしなにしてくれる 得られる結果もjsonを連想配列化したものになる ブラウザでAPIs Explorerを試しながらあれこれ試してみればすぐに理解できると思います。
cgroupsのnamespace手動削除
自宅のPCルーターは10年以上前に構築したDebian環境をもとに、HDDだけ移しながらupgradeを長年重ねて積み上げたもので、.emacsが結構な腐臭を放っているとか自作init scriptをmake styleにいい加減に修正したものがあったりとか、いろいろガタはあるものの今でも元気に動いています。 時代が時代なので当然アーキテクチャはi386なのですが、いまどきはDebian側でi386向けのamd64 kernelパッケージを提供しているので、現在はそれを使っています。メインメモリも8GB積んでいます。 kernelがamd64なので、debootstrapでamd64のuserlandを構築することも可能です(–arch amd64)。最近、これをベースにLXCコンテナ化しました。やることは単純で/var/lib/lxc/$name/rootfsにシンボリックリンクを張って、設定ファイルを適当にコピペででっちあげるだけです。 ただ、この作業の過程の中で、lxc-startを-KILLシグナルで殺してしまい、cgroupsのnamespaceが残ってしまうという問題が発生しました。これをどうやったら削除できるか調べてみた結果、rmdir /sys/fs/cgroups/lxc/$name で削除できることを覚えました(kernel documentのcgroups.txt)。最初 rm -rfで消そうとして消せない、と苦労していたのですが、ディレクトリだけを削除すれば良いようです。逆にmkdirするとblkioとかcpusetとか必要なものがごそっと生えてきます。 というわけで、何かしらの不手際でcgroupsのnamespaceが残ってしまった場合には、ディレクトリだけをrmdirしましょう。 ついでにわかったこととして、LXC 1.0.6ではこういった「同じ名前のnamespaceが既にある」状況では$name-1といった名前で重複しないように作るような動きをするようです。
DebianパッケージでBuild.PLをポリシーに合うように扱う
ちょっと手間取ったので記録に残しておきます。 かつてのPerlはExtUtils::MakeMakerという標準モジュールを使い、Makefile.PLを用意しておくというのが一般的でしたが、最近はそれ以外にもModule::Build, Module::Build::Tinyというパッケージを使い、Build.PLというファイルを用意して処理することもあるようです。dh-make-perlはModule::Buildにも対応しているような感じでしたが、Module::Build::Tinyには対応していないようです(dh-make-perl 0.84-1で確認)。 dhのoverrideを使って、以下のようなコードをdebian/rulesに追加することで望みどおりの動作をするようになりました。 追記 同じ内容の記事を英語blogの方にも書いたところ、debhelperの問題という指摘を受けました。この問題が発生するのはwheezyのdebhelperに限定されます。sidではこのような対応は不要です。
CAT68701にNetBSDを移植したときの思い出
これはNetBSD Advent Calendar 2014の12日目の記事です。 かつてCAT68710というsh3ベースのワンボードコンピュータがシリコンリナックスから販売されていました。標準OSはLinuxだったのですが、それをNetBSDに移植したときの思い出を記憶から掘り起こしてみます。もう10年以上前のことになりますが… まずCQREEKSH3をベースとすることを考えました。これは多分CQ RISC評価キット/SH3のコードです。組み込みsh3ボードは他にも複数あったのですが、なぜこれを選択したのかはよく覚えていません。confの差分を見ると相当いろんなものを削っていたのでどれをベースにしても大差なかったかもしれません。 CAT68710にはシリアルポートがあり、ブートローダーが最初から入っていて制御可能だったので、最初はとにかくシリアルからなにかしらの出力をさせるために、locore.Sをいじってシリアルに文字を出してみるところから始めました。シリアルコントローラはsh3内蔵のものをそのまま使っていたので、ブートローダーが既に初期化をしてる状態からシリアル出力をさせるのは簡単でした。 各種I/OデバイスのアドレスをCAT68710に合わせて起動させると、動いているっぽい感じはあったのですが出力がなにもなかったので困りました。先の「既に初期化されているシリアルポート」であることを利用してputcharに手をいれて、とにかくコンソール出力をさせてみたらpanicに至るメッセージが出力できて、ようやく手がかりをつかんだことが当時の日記に記録されています。 シリアルコントローラは初期化パラメータが間違っていたようで、それを修正して小細工なしにシリアルコンソールが出るようになりました(当時の記録)。さらにpcmciaのコードをmmeyeから持ってきて、CFスロットが認識できるようになりました。 ネットワークはCS8900を使っていて、幸いなことにNetBSD側にMIなドライバーがあったのでそれを組み込みました(記録)。割り込みベクタ番号を適切な値にすることで最終的にちゃんと動くようになりました。適切な値、というのはLinuxの方で設定しているirq番号を参考に適当に何かを足し引きしてたまたま動くやつがわかった、というような経緯だった記憶があります。この時にsh3 Linuxのデバイスドライバは基本x86のISAバスのセマンティックに無理やり合わせて動かしている、ということを学びました。今時のデバイスでは変わっているだろうと思います。 最終的にnfs rootでmulti user modeで動くところまでは持ってゆけました。作業はここで力尽きて止まったようです。 思い返してみると、NetBSDのMIドライバはよくできていたなと思います。既に複数の組み込みボードの移植コードが存在していたことも、自分がポーティングできた成功要因の一つだと思います。多分自分で書いたコード量は3ケタ行ぐらいだったと思います。しかし当時gitがなかったのが残念です。手元に残っていたコードは2つのtarballだけでした。
GData ClientのSpreadsheet ListFeed
個人的にはまったので記録に残しておこうと思います。 GoogleのAPIには2つの種類があります。一つはGoogle APIと呼ばれるもので、APIs Explorerにて確認できるものです。もう一つ、微妙に違うGoogle Data APIsというものがあります。GoogleはこれらのAPIを操作するためのライブラリを各種言語向け(Java, .NET, Python, ruby, PHP等)に用意しています。前者はgoogle-api-clientというような名前、後者はgdataというような名前を付けています。 この2つは微妙にセマンティックが違うのですが、OAuth2で認証できる点は同じで、認証ポイントも同一です。しかしそれぞれ個別にOAuth2認証クラスを持っていたりして、両方をまたいで(たとえばgmailとcalenderの組み合わせ等)使おうとするときは結構面倒です。両方をカバーするscopeでどちらかのライブラリで認証し、もう片方のOAuth2認証クラスに各種情報をコピーする必要があります。 それはともかく、今回はまったのは以前くらった「GData.SpreadsheetsライブラリのListFeedに潜む罠」の続きです。一行目に書かれた文字列がフィールドのキーとなるわけですが、さらにこの値は「API上は小文字しか受け付けない」という罠です。 たとえばA1に「Firstname」という値があったとして、ListEntry.CustomのLocalNameプロパティに”Firstname”としているとAPIレベルでエラーが帰ってきます。ここは”firstname”としなければなりません。 StackOverflowの“Cannot add a row to Google Spreadsheet”という記事でこのことが説明されていました。Google Sheets API version 3.0にはそのことは触れられていません… 毎度StackOverflowにはお世話になりっぱなしです。
Linuxで扱う乱数に関する話
これはLinux Advent Calendar4日目の記事です。 Unix系OSには、カーネルに乱数生成器を持つ実装が多くあります。乱数は暗号分野でも利用され、非常に重要な位置を占めています。Linuxにおける乱数に関する話題を取りあげてみます。 エントロピープール 一般的に、特別なハードウェアを持たない限り、真の乱数を計算機が生成することは困難です。Linuxでは、質の良い乱数を生成するためにエントロピープールと呼ばれる領域を持っています。エントロピープールには、キーボードの入力タイミングやストレージ、ネットワークなどで発生するハードウェア割り込みなどをもとにした推測の困難な情報(環境ノイズ)が蓄積されます。乱数の生成時には、このエントロピープールの内容を消費、加工します。 エントロピープールにどの程度情報がたまっているかを調べるには、/proc/sys/kernel/random/entropy_availを見ます。エントロピープールの上限値は/proc/sys/kernel/random/poolsizeをcatした出力値です(デフォルト値は4096) 。OpenPGPやSSLの鍵などを生成する際には、この値を確認した方がよいかもしれません。 スペシャルデバイス 乱数を生成する特別なデバイスファイルには、/dev/randomと/dev/urandomの2種類があります。 /dev/randomは全ての乱数をエントロピープールから生成します。エントロピーが不足した場合は新たにたまるまでブロッキングされるため、あまり速度が出ません。乱数の質よりも速度に重点を置く場合には、/dev/urandomを使います。urandomを使う場合、エントロピープールを再利用して乱数を生成します。 havege havegedを動かすことで、より多くの環境ノイズ(主にCPUの情報)をもとにしてエントロピープールを常に多い状態へと保つことができます。エントロピープールへの情報の追加は/dev/randomのioctrlインターフェースを用いています。また、havagedは単独の乱数生成アプリケーションとしても利用できます。 NeuG g新部さんによるハードウェア乱数生成実装として、NeuGがあります。NeuGはSTM32F103上で動作し、チップに搭載されているA/Dコンバーターからの入力の量子化誤差を乱数生成に利用します。NueGの動作するハードウェアとしてFST-01があります。この記事を書いている2014年12月初頭では品切れ中ですが、今後追加生産・販売を予定しているそうです。 仮想化の問題 エントロピープールの情報は、予測が困難であるハードウェアからの情報に大きく依存しています。仮想マシンの場合、多くのハードウェアは仮想化されており、ハイパーバイザ等の配下にあります。したがって、物理マシンと比較すると質の良い乱数を生成させることがより困難となっています。セキュリティに十分な注意を払う必要がある場合には、信頼できない仮想マシン上での暗号鍵の生成などは控えた方が良いでしょう。 訂正 コメントでg新部さんからいくつかご指摘を頂きましたので修正・追記しました。FST-01はhttp://www.seeedstudio.com/より購入可能とのことです。詳細はコメントをご覧ください。 宣伝 この記事はFSIJ勉強会での解説をもとに得た知見を自分なりに記録したものです。FSIJでは定期的に勉強会を開催しています。GnuPGの開発者の一人であるg新部さんもいらっしゃるので、興味のある方はぜひお越しください。