Goをビルドしてみた
Google が Go という言語処理系をリリースしたので、さっそくビルドしてみました。
環境
- Debian GNU/Linux
- 2.6.26-2-amd64 #1 SMP Wed Aug 19 22:33:18 UTC 2009 x86_64 GNU/Linux
手順
環境変数の設定
Go では環境変数をいくつか設定しておく必要があります。これはその場で設定するのではなく、~/.bashrc などに書いておく必要があるようです。
また、$GOBIN を設定したところには予め $PATH に追加しておく必要があります。
hg clone
公式ページの手順通りに hg clone します。
% env | grep GO GOBIN=/home/limit/local/go GOARCH=amd64 GOROOT=/home/limit/hg/go GOOS=linux $ hg clone -r release https://go.googlecode.com/hg/ $GOROOT
処理系のビルド
普段 NIS を使っている環境でビルドしたので、さまざまな問題を避けるため
という処理を行っています。こういう変な設定をしていると環境変数がうまく処理できないらしく、単に src で ./all.bash を叩いても動きませんでした。
仕方がないので all.bash の中を見て、ある程度手作業でやってみることにしました。
all.bash は make.bash と run.bash を起動しているだけです。
make.bash の先頭では $GOROOT が正しく設定されているかどうかをチェックしていて、これが上記の原因でうまく通っていませんでした。したがってそこを飛ばして、ビルドを行いました。このスクリプトの中で $GOBIN/quietgcc というスクリプトを生成していて、これを使っているため、 $GOBIN には $PATH が通っていないとダメです。
2009/11/12追記：これはこちらの勘違いだったようで、環境変数を正しく設定していたら上記の処理をした環境でも問題なく動作してくれました。
テスト
テストは run.bash で行われます。これは環境変数を気にせず、そのまま走らせました。
どうやら net のテスト付近で失敗したようです。
2009/11/12追記：このエラーは解消されました（エラーメッセージは下へ移動しました）。詳細は下記。
さしあたり、 src/pkg/Makefile の NOTEST リストに net を追加したところ他のテストはうまくいきました。
多分これのバグレポートを投げたりしないといけないですねー。
2009/11/12追記：投げました！ net: TestDialError fails · Issue #32 · golang/go · GitHub
2009/11/12さらに追記：別の問題にMergeされていて、エラーメッセージが異なるから新たなIssueとして登録したはずなのに何かと思ったらこの net というテスト自体がテスト対象から外されたようです。これでエラーは出ません。net: TestDialError fails · Issue #23 · golang/go · GitHub
基本情報技術者の資格持ってたって無駄
「基本情報持ってます」とか言ってる人は大抵役に立たない可能性を秘めている。
頭でっかちな知識だけが先行していて実感がないから。
実際にあった例
基本情報を持っている人
DBを編集したんだけど反映されない。なぜ？
原因はコミットしてなかったこと。
基本情報の勉強をまともにやれば、当然DBにコミットがあること*1は知っているはずで、もちろんこの人もその存在は知っていた。
でも、自分でDBを編集*2した後にコミットしなければならない、とは思わなかったらしい。いくら難しい insert 文が書けてもそれを反映させる方法が分からないのでは全く無意味。
この人は普段小規模なCのコードをふらふらっと書いてるだけで、基本情報技術者試験の内容とは全然関係ないことしかやっていない。こんな人が資格を持っていても、結局役に立たないし、「持っている」と主張することによって失望される原因となる。
これがもし「コミットする必要がある」という認識があったらどうだろうか？コミットの具体的な手順が仮に分からなかったとしても、質問はこうなるはずだ：
DBを編集したので反映したいがコミットの手順が分からないので教えてほしい
これはどのようなDBMS*3を使うかによって異なってくる話で、資格の有無とは無関係な話だ。
こんな人が量産されるようだと、「基本情報の資格とか役に立たない」と言われるようになってしまうだろう。
決して「知識が無駄」とか「基本情報が無駄」と言いたいのではなく、「知識だけじゃなくて実際に使う能力が必要」と言いたい。
Google Document にファイルをアップロードするバッチを作ってみた
GitHub に上げたので最新ソースは GitHub からどうぞ
http://github.com/limitusus/google_docs_up/
Motivation
普段研究室のサーバにログインして作業することが多いので、メールもサーバ上で Emacs を立ち上げ、その上で Mew を使ってメールを読んでいます。
ときどき添付ファイルつきメールが来ることもあるんですが、 .doc なファイルとか、 .xls なファイルとか、挙げ句の果てには .docx とか .xlsx とかが添付されてきます。
普段は Ubuntu しか使ってないので、 Openoffice.org を使って .doc や .xls まではギリギリ読めるのですが、 .docx とか来るとどうしようもなく、 Google Docs にアップロードすることで開くという対処法が存在していました。
前述したとおりメールはサーバ上で読んでいるので、アップロードを Web 上で行うためには、
- メールを受信する
- 添付ファイルをサーバ上のどこかに保存する
- 添付ファイルをローカルマシンに持ってくる
- Web上でアップロード処理を行う
- 添付ファイルを見る
というプロセスが必要です。これはいかにも時間がかかる作業で、真のプログラマなら面倒で到底やってられないでしょう。
自然に考えて、
- メールを受信する
- 添付ファイルをサーバ上のどこかに保存する
- 添付ファイルをサーバから直接アップロードする
- 添付ファイルを見る
となっているべきです。
これを実現するため、 Google Documents の API を利用することにしました。
API の詳細はこちら。
Protocol Guide (v3.0) - Google Documents List Data API v3.0 - Google Code
Get API Library
Google Documents の API ライブラリは以下のページから入手できます。
Client Libraries and Sample Code - Google Documents List Data API - Google Code
今回は Python の SVN から引っ張ってくることに。
Python Client Library Project -> Source
とたどると、チェックアウトの方法が分かります。ここには Subversion によるチェックアウト方法が書かれています。
tarball でも SVN でも、とにかく持ってきて展開すれば、 setup.py などが手に入ります（ここでは git-svn でチェックアウトしました）。
~/git/gdata-python-client % ls INSTALL.txt MANIFEST README.txt RELEASE_NOTES.txt build pydocs samples setup.py src tests
Install API Library
API ライブラリをインストールします。これは setup.py がやってくれます。詳しくは INSTALL.txt を読んでください。
私はいつも ~/local 以下にいろいろ置くことにしているので
~/git/gdata-python-client % ./setup.py install --home=$HOME/local
としてインストールしました。
これにより、 $HOME/local/lib/python 以下に Google Documents API Library がセットアップされます。
このようにセットアップを行った場合、環境変数 PYTHONPATH に $HOME/local/lib/python が含まれている必要があります。必要に応じて設定します。
Modify API Library
実は 2009/09/29 現在の Python の API は PDFのアップロードに対応していません（Java は対応しているらしい）。
そこで、少し修正を行います。
Issue 591 - gdata-issues - Allow Upload of PDF Files to Google Docs - Project Hosting on Google Codeの Comment: 77 に修正が書かれています。
修正するファイルは [--home で指定したディレクトリ]/lib/python/gdata/docs/service.py です。
- uri = の行の変更
- GData-Version の追加
の2ヶ所です。
Usage
作成したプログラムに実行権限を付けて PATH を通しておけば、
$ google-docs-up hoge.pdf $ google-docs-up hoge.docx
などとするだけでファイルがアップロードされ、閲覧するための URI が表示されます。
% google_docs_up hoge.pdf ('hoge.pdf', 'hoge.pdf', 'pdf') Document now accessible online at: http://docs.google.com/fileview?id=ファイルID Current Documents list: hoge.pdf
のように出力され、上で表示された URI にアクセスすれば Google Documents 上でファイルを閲覧できます。
コードは続きで。
ドワンゴインターン2008/2009
注意：ここで書かれているのは基本的にドワンゴインターン2008の内容です。
去年 ドワンゴインターン行ってきた - Limitの日記
インターン2008
どうやらインターン2008の内容はほとんどしゃべっちゃって大丈夫らしい（というか、既に公開されてるとか）ので、もう少し技術的に詳しいところを書こうと思います。
インターン2008は2チームに分かれていて、もう片方はd:id:con_mameが2009-09-16
やったこと
ニコニコ動画の各動画につけられるタグの情報を利用して、タグ荒らしを検出しよう
状況および目的
動画にユーザが自由につけられるタグだが、自由なのをいいことに好き放題タグを編集しまくる人がいる。
場合によってはそれが人間の手によるものではなく、タグ編集ツールだったりする。
このようなユーザを的確に発見したい。
基本アイデア
あまり細かいところは荒らしにさらなる対策をさせることになるので言わないほうがいいと思うので言わないけど、
荒らしの特徴として
- タグの編集回数が異常に多い
というのが挙げられる。これは実際かなり単純な方法なのだが、タグ編集ログに対して、編集回数が多いユーザの上位にはかなりの確率で荒らしユーザと思われる行動がみられた。
生じた議論
ここで、そもそも「タグ荒らし」とはどういうものを指すか、ということについての検討が行われた。
実はインターンの期間の中でかなりの時間、「タグ荒らし」とはどのようにして（定量的に）定義すべきか、という議論が行われた。
最終的に採用された方法
タグの言葉を形態素解析→意味解析して、荒らしっぽいとかを判定するというのも方法としてはあるのだが、それほど詳しい知識があるわけでもないので、別の手段を検討した。
タグの編集回数が非常に多いユーザを見ていると、「わけわかんないタグばっかり付けてる人（＝多分荒らし）」と、「マイナーなタグをメジャーなタグに付け直している人（＝タグの直し屋）」がいることが分かった。
この事実をヒントに、[自主規制]に各編集行為を分類し、それぞれパラメータをいじることによって「荒らしのように見える人」「直し屋のように見える人」というのを、タグ編集回数が多い人について振り分けることになった。
最終的には人間の目で見てみるしかないが、最終日の段階では約7割の精度で荒らしの判定を行える、という状態になった。あの段階で満足しているわけではなかったんだけど、あの時は精一杯だったと思う。
インターン2009
見学させていただけるということで、インターン2009の最終成果発表会だけ見学に行かせていただきました。
インターン2009の内容についてはd:id:marimofireがhttp://d.hatena.ne.jp/marimofire/20090914/1252949002
今回は技術系のインターン生3人だけということで規模が大きかったわけではないですが、成果としてある程度まとまったものもできていたし、立派に発表できていたと思います。社員の方が約20人くらい聞いていたというのもあって、発表している側は結構緊張していたようです。
3人とも、おつかれさまでした。
JauntyにアップグレードしたらGnomeのメニューが動作しなくなった
この間使っているUbuntuをHardyからIntrepid、さらにJauntyへとアップグレードした。
それ自体は、アップグレード中にログアウトしていまいXが起動不能となり冷や汗かきながら復旧したことを除いて何の問題もなくうまくいったように見えた。
ところが問題は見えないところで発生していたらしい。
システム->設定->メインメニューをいじろうとしてクリックしてみても、何も出てこない。Hardyの時には設定画面はちゃんと出てきたはずなのに…何かおかしい。
これは"alacarte"というプロセスなので、何が起きているのか見るためにターミナルで叩いてみた。
% alacarte Traceback (most recent call last): File "/usr/bin/alacarte", line 22, in <module> from Alacarte.MainWindow import MainWindow ImportError: No module named Alacarte.MainWindow
alacarteはPythonで書かれていて、Alacarte.MainWindowをimportして実行するだけのシンプルなスクリプトだった。このimportに失敗した、ということらしい。
とりあえず検索してみた。
Bug #358181 in python-central (Ubuntu): “alacarte crashed with ImportError in
ちゃんと他にも同じ状態になっている人はいたようで安心。このページの最後に解決法へのリンクが載っていた(Jauntyのリリースノート)。
9.04 Release Notes | Ubuntu
これに従い、
% sudo dpkg-reconfigure alacarte
で解決。
他にもあるかも。
追記:システム->設定->ソフトウェア・ソースも起動しませんでした。これは
% sudo dpkg-reconfigure python-software-properties
が解決法？っぽい。(いろいろreconfigureしてみたけど最後にこれで直ったので…)
ghcまわりのパッケージが壊れたらしい
どうもaptでいろいろやってるうちにパッケージを壊してしまったらしい。
% sudo apt-get update % sudo apt-get upgrade
などすると最後にこんなメッセージを吐いて終了してしまう
libghc6-http-dev (30010004-2) を設定しています ... ghc-pkg: cannot find package HTTP-3001.1.3 dpkg: libghc6-http-dev の処理中にエラーが発生しました (--configure): サブプロセス post-installation script はエラー終了ステータス 1 を返しました 以下のパッケージの処理中にエラーが発生しました: libghc6-http-dev E: Sub-process /usr/bin/dpkg returned an error code (1)
% sudo apt-get -f install
としても効果なし。ぐぐってみるとDebianのバグトラックページを見つけた(#510499 - ghc-pkg --global will still look in user config - Debian Bug report logs)
これに従い
% sudo -H apt-get -f install
としたら問題が解消した
パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 0 個。 1 個のパッケージが完全にインストールまたは削除されていません。 この操作後に追加で 0B のディスク容量が消費されます。 libghc6-http-dev (30010004-2) を設定しています ... Reading package info from "/usr/lib/haskell-packages/ghc6/lib/HTTP-3001.0.4/installed-pkg-config" ... done. building GHCi library /usr/lib/haskell-packages/ghc6/lib/HTTP-3001.0.4/ghc-6.8.2/HSHTTP-3001.0.4.o... done. Saving old package config file... done. Writing new package config file... done.
sudo -Hオプションはsudo中にHOME環境変数を/rootに設定してくれるものらしい。ghc-pkgがHOMEに依存してたということみたいですね。
Rakudo Perl6をソースからビルドしてみた
Perl使いとしてはやはりPerl6のビルドくらいはやっておかないとということでやってみた。
Parrotのインストール
% svn co https://svn.parrot.org/parrot/trunk parrot % cd parrot % perl Configure.pl --prefix=/home/limit/local % make % make test % make install
revは39563だった。
/home/limit/local/bin/の中にparrotやparrot_configがあることを確認
追記(2009/09/25):
2009/09/25時点での最新版では以下のPerl 6のConfigure.plで
% perl Configure.pl --parrot-config=/home/limit/local/bin/parrot_config Reading configuration information from /home/limit/local/bin/parrot_config ... Verifying Parrot installation... ===SORRY!=== I'm missing some needed files from the Parrot installation: /home/limit/local/lib/parrot/1.6.0-devel/languages/nqp/nqp.pbc /home/limit/local/lib/parrot/1.6.0-devel/tools/build/ops2c.pl /home/limit/local/lib/parrot/1.6.0-devel/tools/build/pmc2c.pl /home/limit/local/src/parrot/1.6.0-devel /home/limit/local/src/parrot/1.6.0-devel/pmc /home/limit/local/include/parrot/1.6.0-devel/pmc (Perhaps you need to use Parrot's "make install-dev" or install the "parrot-devel" package for your system?)
というメッセージが出てしまった。
したがって、この時点で
% make install-dev
も叩いておくべきらしい。
Rakudo Perl 6の構築
自分でインストールしたParrotを使う方法がなぜかREADMEに書かれていなかったのでConfigure.plを解読。以下のように指定すればいい。
% git clone git://github.com/rakudo/rakudo.git % cd rakudo % perl Configure.pl --parrot-config=/home/limit/local/bin/parrot_config % make % ln -s `pwd`/perl6 ~/local/bin/ % cat > ~/hello.pl "Hello World!".say ^D % perl6 ~/hello.pl Hello World!
~/local/bin/parrot_configを指定したんだけど~/svn/parrot/parrotを使っているらしい。
Rakudo Perl 6ではmake installにあたるものをまだ作ってないらしいのでsymlinkを張っておいた。
