2008年12月6日土曜日

フリーランスを代表して申告と節税について教わってきましたを読んだ

あーそろそろ年末だし、税金とかどうすっかなー、ってかおれ全然知識無いじゃんヤバイよおれ、と思って速攻amazonで買って、届いたその日に徹夜して読みました。(笑


"フリーランスを代表して 申告と節税について教わってきました。" (きたみ りゅうじ)

フリーランスを代表して申告と節税について教わってきましたを読もうと思った理由

  • もともと税理士の勉強しようかなぁと思ってたので、こういうのに興味があったから
  • フリーランスとしてやってくのと、会社員としてやっていくのは、どっちにどんなメリットがあるんだろうと思ったから
  • amazonの評判が良かったから(結構amazonのコメント見て決めるの多いなぁ)
  • 「フリーランスを代表して〜」なので、立場的にぴったりだったから

フリーランスを代表して申告と節税について教わってきましたってどうよ?

  • タイトル長いよ
  • 基本的に、フリーランサーの著者と、税理士の先生が会話するスタイルで書いてあるので、とても読みやすい
  • 申告とか税理について、現実に即した視点で、仕組みからポイントまでわかりやすく解説している
  • 読みやすい割に、ぶっちゃけが多くて実用的。まぁ、税理の面白い面というか、節税のキモというか
  • 「一人で仕事してます」みたいな規模をターゲットとしているので、立場的においらにピッタリだった
  • 青色申告って何がうれしいのか、どこまでが必要経費?とか、勘定科目はどれにしたらいいの?とか、税務調査って実際どうよ?的な、本当に知りたいところがきっちり書いてあって良い感じ

で、どう思ったか?

  • 考え方とか要点は、この一冊で十分だと思う
  • 細部は省いてあるので、本格的にやるならハンドブックがもう一冊必要だと思う
  • さくっと読めて実用的なので、時間がない人や、本格的に覚える前の総論的な使い方がオススメ
  • 買って良かったです

オススメできるか?

んーと、フリーランサーは間違いなく読んだ方がよいです。

2008年12月5日金曜日

英語嫌いの東大卒が教える私の英語学習法を読んだ

ええと、最近マジメに英語を勉強しているのですが、どう勉強したら効率的なのか疑問に思う部分もあったのでこの本を読んでみました。


"英語嫌いの東大卒が教える私の英語学習法 (アスカカルチャー)" (小川 慶一)

英語嫌いの東大卒が教える私の英語学習法を買おうと思った理由

  • サイトで紹介されていて、結構評価が良かったので興味を持った
  • 実際に本屋で立ち読みしてみて、あーなるほどねーと思う部分があったので買ってみた
  • 特に、うまく勉強時間を確保して、如何に効率的に勉強するかを、科学的に理論立てているのが気に入った

英語嫌いの東大卒が教える私の英語学習法ってどうよ?

  • TOEICで点を取りたいなら、まずはボキャブラリ重視。TOEIC500点ぐらいから文法知識も重要になるけど、最終的にはやはりボキャブラリが重要になる。
  • 覚えたことを忘れないようにするには、まず復習すること。そして覚えるときに強烈なショックを覚えること。でも、極論的にこの二つは同じ事。
  • パッシブ・レビューよりアクティブ・リコール。要は、何度も読み返すより、考えたり書いたりする方が効果的。
  • 人間が一度に覚えられる数は7個まで。これをチャネル・キャパシティーと言う。
  • 効率的に覚えるには、背景事情や理論から覚える、各論より総論から覚える、順番を入れ替えたり、カテゴリー化したり、語呂合わせと音で覚えたりすると良い
  • 単語はコンセプトで覚え、訳は覚えない
  • 「マクドナルド」を聞き取れないとき、日本人は「まー・くー・どー・なー・るー・どー」と同調同長で言うけど、英語圏の人は「ダナーズ」と強弱をより強調して言う。これが日本語と英語の音の違い。
  • ラテン語系の単語は、語源に接頭辞・接尾辞などをつけて機械的に組み立てられたような構造になっているものがある。語源の数は数百だが、そのバリエーションは多く、要点さえ覚えれば理解もしやすい。
  • 語学の勉強では、わかってもわからなくてもいいから、適当にがんばったらさっさと次に進むのが大事
  • 成果 = 環境 × 集中 × 時間

で、どう思ったか?

  • 私の英語学習法と題しているだけあって、効率的な学習法と、学習時間の確保の仕方や、効率的な時間配分など、実践に即した内容に、大きくページを割いている
  • 学習内容はTOEICに絞ってあるので、この通りにやるだけだと、読めるけど、書いたり話したり出来ないと思う。ただ、効率的に学習するには、ちゃんと読めるようになってから、書いたり話す練習をした方が良いと他の本にも書いたあったような。
  • 結構さくっと読めて、それでいて気持ちいい。理解した気になる。
  • やっぱり如何に効率的に勉強するかを、科学的に理論立てているのは、読んでいて気持ちが良い。(プログラマだからなんでしょうねぇ)

オススメできるか?

英語学習に限らず、語学系の学習、もっといえばあらゆるモノの勉強をする前に読んでおくことをオススメします。特に会社員など、時間が限られてしまう方へ。

自分の子供が大きくなっても、機会があれば読ませると思います。

関連すると思われるサイト

ボキャブラリ重視というあたりは、結構核心突いてる気がする。

英語ができないたった1つの決定的な理由

2008年12月4日木曜日

フォーカスリーディングを読んだ

最近色々思うことがあって、年末年始はたくさん本を読もうと思っています。

で、おいらは他人様より本を読むのが遅いので、このまま読むとすごい時間を消費してしまいそうだったので、最近売れているらしいフォーカスリーディングという本を読んでみました。


"フォーカス・リーディング 「1冊10分」のスピードで、10倍の効果を出す いいとこどり読書術" (寺田 昌嗣)

フォーカスリーディングを買おうと思った理由

  • 大量の本を読むための時間を節約しようと思ったから。
  • ソレ系のサイトでとりあげられていて、まぁ、悪くない評判だったので。
  • amazonのコメントなどで、昔の有名な本の焼き直しみたいなことも言われてるけど、逆を言うとそれって結構的を得ていることが書かれているってことだよね?
  • 「10分で本が読める」とは言ってないこと。「1冊10分のスピードで、10倍の成果を出す」と書いてあるだけで。要は妖しげ速読術の本では無いと思ったから。

フォーカスリーディングってどうよ?

結構はっとすることが色々書いてあります。

  • この本は、「本を早く読むための本」では無い
  • この本は、「如何に効率的に読書によって知識を得るか」について書かれた本。要は「本の読み方」について書かれた本
  • 読書の投資対効果 = (著者の力 × 読者の経験値) / 読書にかけたコスト × あなたのビジネス力
  • 本を読む前に、なぜ本を読む必要があるのかを明確にする
  • 全文を読む必要はない。細部を捨て、必要なところだけ読む
  • 1回で全てを読むのは非効率かもしれない。実は浅く数回読んだ本が理解が早いかも知れない。
  • 得るものが少ない本は、途中でも読むのを止める。おいらの場合、本の価格より本を読むための時間コストの方が高い。得るものが少ない本を読むより、プログラミングした方が良い。
  • 本を買わずに、本を読んだ友達をお茶に誘って、ポイントを聞き出した方が効率的かも
  • 狩猟採取型読書と農耕型読書を意識する
  • 一応速読についても書いてあるけど、あまり重点は置いてない。こういうことができたら、読み方に幅が出来るよー程度。でもかなり具体的に書いてある。

で、どう思ったか?

  • どちらかというと、おいらが良く読むような技術書ではなく、ビジネス本を読むときのことを対象に書いてある気がする。技術書だと、前提条件が分からないと以後の話が理解できないので、飛ばし読みできないからね。
  • 全文を読む必要はない、という部分には結構ショックを受けたかも。確かにそうだよねー。読む速度が遅いなら、如何に読む文書量を少なくするか、に重点を置くべき。
  • 速読については、あーそうなんだー程度。おいらにとって速読はやはり嘘臭さがあるので、「全文読まない」の方がインパクトがあって、現実的に思えた。
  • 大事なのは、本を読むことではなく、本から得られた知識を使うこと

オススメできるか?

うん、1100円と安いし、本をたくさん読む必要がある人や、上記で興味を持った人は読んでみると良いと思います。あると思います。

この本を読んだあとに見たら良いと思うもの

本の選び方が参考になりました。。

桁外れの数読むためのインプット&アウトプットする方法

いつもたくさん読んでいる人のノウハウ

読書を単なる知識取得ツールで終わらせるのはモッタイナイ!

中古本の横断検索サイト。有名な本なら結構安く手にはいるかも。

古本販売サイト一括検索

2008年12月1日月曜日

android勉強会 in 札幌+android周辺事情のまとめ

11/28にJavaFesta2008にてandroidに関するセッションが、11/29にandroid勉強会 in 札幌が開かれ、勉強会に関してはスタッフとして参加してきました。

1週間前まではandroidに関してあまり知らなかったのですが、スタッフになった関係もあって今週ちょこちょこと情報を集め始め、勉強会などを通していろんな情報が集まったので、まいむぞうの主観で見たandroid観+勉強会まとめ+ぶっちゃけトーク的に列記してみます。

androidの採用に適した状況

正確にはandroidの採用に適している(とまいむぞうが勝手に思っているもの)です。

  • 外出中に座っている状況以外で使う(=ノートPCは使えない状況。処理能力や表現力はノートPCには敵わない)
  • 常駐アプリを常に起動しておくような使い方(=その場その時に合った情報を提供。秘書アプリなど)
  • 組み込み業務系ハードの制御用フレームワークとして。既存の組み込み向け開発環境は、専用のIDEとCまたはC++の組み合わせであり、独特の進化を遂げてきた(=一般的なJavaの開発環境水準には遠く及ばなかった)が、一気に追いついた(=開発コスト減少)。またフレークワーク部分のソフト代金が不要になるので、一台当たり単価も下がるのでは? これと相まって、今まではハードの調達コストや組み込み用のプログラミング環境を使わざるを得ないので参入障壁が高かったものが、androidであればかなり下がるのでは? 特にタッチデバイス系など。

大事なこと

  • 最初から全世界を狙うべき(日本での展開がどうなるか、受け入れられるのかも含め、防衛戦は張るべき)
  • androidではintentを通して他のアプリに問い合わせが出来る以上、早期にシェアを取ってしまえばその類のデータプロバイダとしてデファクトを取れる可能性が高い(ユーザとしては同種のソフトを複数入れるより、1つで済ませたいはず。容量的アプリ間の相性的に)
  • 携帯用ソフトは無料もあるけど、実用性が高ければ有料でも買う、という風潮がある(=良いモノは販売できる。広告モデルに頼らない。iPhoneはこれでいいが、androidマーケットはちょっと風潮が違う可能性も…)
  • 現状、英語読めないとキビシイ(ドキュメントがほとんど英語)
  • 勉強するならみんな1つづつ作りたいアプリを考えて、コツコツ作っていくのが一番良いのかも。

ぶっちゃけどう?

  • Javaであるための3大要素である「文法」「標準ライブラリ」「バーチャルマシン」のうち、androidは文法しか準拠してないので、Javaとは似て非なるモノとして扱わなければならない。
  • とはいえ、ソースコードレベルでは標準ライブラリもそこそこ同じモノが入っているので、既存のJava用サードパーティライブラリも、とりあえずコンパイルしてみて通れば使えそう。方向性としてswingなどのGUI系ライブラリはごそっと落ちているみたい。(これって結構楽しい未来が待ってる気がしませんか?)
  • 現状のandroidはG1専用のコードも混じっているなど、まだ完成とは言えないレベルのようだ。ぶっちゃけG1発売前は相当厳しかったらしく、ハードメーカーが相当頑張ったらしい。
  • このような事情から、android搭載機が出たての数台は、android間でも互換性問題が浮上するかも? 実際問題、エミュレータでは動作するけど、G1では動作しないアプリケーションが大量にandroid marketに登録されているらしい。(どうすんのコレ?)
  • FlashLiteではなくFlash 10ベースのプレイヤーがandroidに載ったというニュースが流れて居るみたいだけど、ぶっちゃけ完成度は「いまひとつ」らしい。具体的にはFlexはまだ動かないんじゃないかな、みたい。ただ、相当気合い入っているようなので、これらの解決は時間の問題っぽい。

個人的に聞きたかった事

主にネットや本や勉強会など多方面から収集したものです。

  • androidの海外での反応は? 盛り上がってる? →一般ウケのレベルはちょっと把握できてないけど、開発者レベルの話であれば、本家googleグループへの投稿量がハンパ無いことからかなり注目されているのでは? ちなみに日本以外では本家が活動の拠点のようです。(ので、まじめにやるなら追っかけるべき)
  • layoutとstrings.xmlを分けている理由って、多言語に簡単に対応するためだと思うけど、具体的に言語リソースを変えるにはどうすればいい? →本に書いてあったので読めばいい
  • 日本でのandroidリリース情報は? →来春(4月か5月)ぐらいかな?
  • ケータイとしてのandroid以外の状況は? 業務用組み込み機器とか。 →android周辺ではarmadilloが注目を浴びている。実際に展示会などでもかなり手応えがあるみたい。
  • androidでゲームは作りやすい? →良い面と悪い面があるけど、メモリとCPUの分携帯アプリよりは作りやすい。
  • androidはどうやって配布するの? →コンパイルするとapkファイルが出来るので、これをデバッガ経由でインストールするか、HTMLに貼っておいてクリックしてインストールするか、android market経由でインストールする。
  • android marketからアプリをダウンロードしてエミュレータで動かすことは出来る? →現状、G1などの実機でなければandroid marketにはアクセスできない。ただし、今は有料ソフトがないので、手元にapkファイルがあればエミュレータなどにインストールできるかも。
  • QR画像を解析して文字を取り出すようなライブラリは存在する? →Javaの既存のライブラリでそういうのがあるらしい。(未確認)
  • たとえば、新しいセンサーなどをメーカーが作って、それをandroidにくっつけたとして、android用のデバイスドライバを新しく書くのって難しい?(携帯端末としてはあまり出ないだろうけど、armadilloとしてなら需要が高い気がするし、簡単にできるのか、それなりに時間が掛かるのかによっても状況は変わる気がする。 →まず、市販されるandroidはコア部分をいじれないようになっているので、基本的には追加デバイスは扱えない。エミュレータもしくはarmadilloならばこのあたりも可能だが、アットマークテクノさんに聞いてみたところ、まだデバイスドライバの詳細は掴めていないみたい。ちなみにgainerをくっつけるサブプロジェクトが動いているみたい。(というか半分当事者なんですが)
  • activityって一言で言うと何? 一時期にアクティブになれる一単位という理解は正しい? →基本的には画面一枚と思って良いみたい
  • 参考にarmadilloのロット単価知りたい →話を聞くと、色々組み合わせがあるようなので、やはりアットマークテクノさんに直接聞いた方が良さそう。
  • 業務用機器のように、電源入れたら特定アプリだけが立ち上がるようにできるか? →標準のランチャーもいちアプリケーションなので、これを差し替えれば可能かも。(未確認)
  • T-MobileのG1を入手する方法は無い? →ヤフオクで普通に売ってるね。使用上の注意はあるみたいだけど。
  • android marketでの収益性ってどう? →iPhoneのAppStoreとはビジネスモデルが違うし、まだ決まってない部分が多いので、正直分からない。が、有料化開始までにある程度の期間があるため、有用なアプリは無料期間中に出尽くしちゃって、「アプリは買うもの」という文化にならない可能性もある。
  • android marketって登録するのって難しい? →実は簡単らしい。$25払って、登録時に自分の証明書でデジタル署名する必要があるみたい。
  • 赤外線通信ってサポートされてる? →たぶん、ないような気がする。

Macにセットアップするなら

自分でセットアップしたときのメモです。ネット上にMac用の設定が見あたらなかったので。

  • エミュレータ初回起動時にandroid用のデータ格納先を聞かれるので、~/.androidを先に作っておくと良い
  • JDKはSunからじゃなくてAppleから出てる。ソフトウェアアップデートで入る
  • envでJAVA_HOMEがあるか確認。無ければ作っておくと良い。
  • インストール済みJDKは/System/Library/Frameworks/JavaVM.framework/Versions/に置いてあるはず
  • keytoolのパスはwhich keytoolで探すのが早い
  • MacでAndroid API Key用のfinger printを取得するには/usr/bin/keytool -list -keystore ~/.android/debug.keystoreでOK。~/.androidは先に作ったパス

まぁ、あまり重要なことではないのですが。

androidやるなら一度は見ておくべき

市販の本である


Google Android入門 ~携帯電話開発の新技術」で周辺事情を押さえ、


"Google Android完全解説 (アスキームック)" (アスキー)で実際のプログラミングに必要な知識をおさえると良いかも。

これ作ったらどうよ?

個人的に思いついたandroid用アプリのアイデア。(まだまだですな)

  • 絵文字対応メーラー(UTF8で絵文字サポートという流れもあるようですが…)
  • 飲食店の待ち行列の管理(順番が来たらメールで通知)
  • 自分のgoogleカレンダーからのスケジュールを読んでサービス提供&秘書ソフト

今後の予定

「札幌Javaコミュニティ内日本androidの会北海道支部」ぐらいのスタンスで、北海道におけるandroid関係の活動を続けていくことになりそうです。(詳細は検討中)

ただ、いかんせん人前で話せるほど知識量がないので、札幌Javaコミュニティ内でちょっと時間もらって「今こんなアプリ作ってます」とか近況報告し合ったり、北海道のandroid関係者が集まって呑めるような感じにもって行けたらいいなぁというところです。札幌にはアットマークテクノさんやハドソンさんも居ますしね。

札幌Javaコミュ自体も、特定のJava技術に偏るものではなく、参加者の興味対象によって会の性格が変わるものなので、android勉強会に参加した方で、android技術者間のネットワークを持ちたい方は、札幌Javaコミュニティに参加してみてはいかがでしょう?

2008年11月6日木曜日

プログラマに統計学が必要な理由

最近統計学を押さえる必要性を感じて、完全独習 統計学入門(小島 寛之)を読んだ。

どこに統計学を学ぶ必要性を感じたのかと、その必要性に対してこの本はどうだったかというレビューをまとめたいと思う。


"完全独習 統計学入門" (小島 寛之)

統計学を必要と感じた理由

これは2つある。

ひとつの理由は、Webサービスのためのマーケティングをしたいなら、統計学は必要だよなと、Yahoo!リサーチの価格を調べながら思った。自分の質問に対して、何個の回答があれば十分だと言えるのかわからなかったからだ。で、その場でググっても、表面的なものしかわからず、しかもそれが正しいのか、どういう風に使えばいいのががわからなかった。

後日談で言うなら、"完全独習 統計学入門"を読んでも、この回答数をどうすればいいかはわからなかったので、他の本を読む必要がある。(調査は"完全独習 統計学入門"が対象とする話ではないんだと思う。なにか良さそうな本を知ってる人が居たら教えてください)

もうひとつの理由は、レコメンドシステム(推薦システム)を構築するときや、経営判断を行うときに統計学の知識を使いそうだ、ということがわかったから。

と言っても、「基礎理論からしっかり積み上げてきて、その応用として意志決定のために統計学を使う」って話なら遠回りすぎるので、もっと実践的に「このコードで結果を出すことが出来るんだけど、そのままじゃ式の意味がわからなくて応用できないから、考え方を知る上で基礎理論を勉強しよう」って流れなんだけど。

で、一時期ブログで話題になってたし、Amazonでも高評価だったので、"完全独習 統計学入門"を読んでみたという流れ。

完全独習統計学入門ってどうよ?

この本に書いてあることをまとめてみる。

  • 正規分布なデータであれば、平均と標準偏差が重要。
  • なぜなら、正規分布は計算によって標準正規分布と見なすことができ、標準正規分布の特徴については研究が進んでいるので、少量のデータから色々なことが分かる
  • ある条件下で検定(特定の値はあり得るか)や、それを応用した区間推定(x1~x2に値が収まる確率は何%)を使うと、高確率で未来を予測できる
  • 平均については理解が簡単だとして、あまりなじみのない標準偏差についても、深く知れば生活の上での考え方に幅が出てくる
  • 標準正規分布に対する研究が進んだことによって、現在では数個のサンプルを得るだけで、母体を高確率で推定することが可能

で、どう思ったか?

たしかに、確率や微分積分などの数学の知識は必要なく、読みやすい文章(読むのが早い人なら半日ぐらいか)を読むだけで統計とはなんぞやの考え方部分を理解することが出来たし、正規分布だとわかっているだけの状態から数個のサンプルを得るだけで母体を区間推定する方法など、かなり実践的な知識を得ることが出来た。

まぁ、数学部分をはしょってるので、応用は利かないと思っているけど、何かをするとき統計学のエッセンスを使うことはできると思う。

オススメできるか?

本当に区間推定をするまでの最短経路しか触れていないので、短時間で凄い知識量を得た気になる。そういう意味でオススメ。

でも、実際には骨だけで肉が無いわけで、この本だけで統計を使いこなすのはムリだとも思う。

まぁ、統計学の一番の基礎理論は理解できたので、必要なら実践的な知識を付加することもできるだろうし、レコメンドシステムなどの基礎知識としても使えると思う。

2008年11月2日日曜日

第1回北海道情報セキュリティ勉強会に参加しました

第1回北海道情報セキュリティ勉強会(通称せきゅぽろ)へ参加してきました。

今回は第一回ということもあって、がっちりセキュリティというよりは、セキュリティ周辺事情といったノリでしたが、参加費1000円にもかかわらず、50人弱の参加者が集まり、期待の高さを伺わせました。

サイボウズの竹迫さんや、まっちゃだいふくさんのトークは会場を沸かせましたが、もっと突っ込んだ話を聞きたかった人も多かったはず。

東京と比べて札幌は保守要員より開発者が多いらしいので、(勝手に)開発者を代表して、次回聞きたいことをまとめます。

ちなみにおいらサーバも立てれるプログラマ、という立ち位置なので、ちゃんとしたセキュリティの知識があるわけではありません。的外れだったら突っ込みよろしくお願いします。

実践的なセキュリティ対策の要点

まず、実践的なセキュリティ対策の要点って大きく分けると以下の5つなのかなぁって(勝手に)思った。

  1. 不要なサービスやデーモンを停止する
  2. 色々なログを取り警報を出す
  3. セキュリティスキャナで既存のシステムをチェックする
  4. (ログやスキャナやニュースなどで)見つかった穴を埋める
  5. 定期的にバックアップ

で、この5つが正しいと仮定すると、ある程度の所までは定型パターンに落とし込める気がした。

たとえば、RedHatをPHPとMySQLを動かすWebサーバにするならば、デフォルトで起動している○○と××デーモンは不要(1)で、my.confで△△の設定はOnにしてバイナリログやスロークエリーログなどを有効(2)にし、snortやswatchなどの網を張る(2)。その上で完成したシステムに○○スキャナや××攻撃を仕掛けることよってセキュリティをチェック(3)し、見つかったセキュリティホールの原因がデーモンならばパッケージシステムのアップデートやパッチを(4)、構築したアプリケーションが原因ならばその是正措置をとり(4)、ありかじめ打ち合わせ済みのリスクを担保できるよう、LVMでスナップショットを取って丸ごとバックアップするシステムを構築の後テストする(5)。みたいな。

実際はもっともっと細かいんだろうけど、それでもチュートリアル風に落とし込むことは可能で、それだけでそこそこセキュリティは保たれる気がする。しかもここまでの流れって、費用対効果的には抜群なんじゃないかな。ちゃんと出来てない人いると思うし。

もしこれが可能ならば、ぜひ勉強会で共有したいなぁ。

無料でどこまで現実的な対策が出来るか? その閾値は?

おいらのように、1件数百万の仕事をしている人だと、セキュリティ専用のプロプライエタリ製品まで予算が回らない。

じゃあ何もしないとかというと、オープンソースモノである程度まではいけるんじゃないかと。

上の例が既にそうなんだけど、(あまりガチガチにして運用が大変になるようなものは除外して)オープンソース同士の組み合わせでどこまでの事が出来て、「どういうケースだと、プロプライエタリ製品を使うことで、どこまでの問題がクリアされるか」っていうあたりがノウハウになる気がするので、こういった事例を共有できればいいなぁ。

プロプライエタリ製品が嫌いって事じゃあないんだけど、それがなきゃ何も出来ない訳じゃあないだろうし、費用対効果的に、プロプライエタリ製品を使うべき閾値を共有したいだけなんだけど。

システムの性格による使い分け

お金を扱うシステムなのかとか、保守要員は居るかとか、そもそも保守に当てる金はもらってるのか、などなど扱うシステムによってどこまでセキュリティを確保するか異なってくる気がする。

先のチュートリアルにしても、

  • やっべぇので手間を惜しまずガチガチセキュリティ重視
  • 完全自立でヤバイときだけ教えてくださいな運用手間重視
  • 結局は壊れたときに直せれば良いんでしょなバックアップ重視
  • 自社システムなのでリスクは許容するけれどな予算重視

とか、現実的に採用可能な方針ってのは複数ある気がする。

新しい製品やサービスによって今までの世界観が覆るようなもの

たとえば、バックアップシステムなら、深夜にシステムを止めてサーバ毎に接続してあるオートローダのテープにバックアップするんじゃなくて、LVMでスナップショット取ってAmazonS3に転送しちゃうとかね。

保管場所や帯域が許せるなら、AmazonS3は安価なシステムのバックアップ先としてかなり有望だと思うんだ。

で、こういった選択肢に含まれるような製品やサービスの情報を共有できればいいなぁとか。

対象システムによって開催日を分けるとか

そもそも、WindowsなのかLinuxなのかで実際の対策は大きく違ってくる気がするので、概念的な話だけする日、主にLinux関係の話をする日、主にWindows関係の話をする日に分けてもらった方が良い気がする。

個人的には、Windowsを使ったシステムを構築するつもりはないので、Windowsの話ならば参加しないと思う。


そんなこんなで、今後のせきゅぽろに期待!!


2008年10月31日金曜日

gemspec.infoのβバージョンをリリースしました

えーと、札幌Ruby会議01以降あまりいじってないのですが、一応αバージョンからβバージョン扱いに移行しました。

バージョンアップ内容

  • ほぼ全てのバージョンの詳細情報を入力させた(いくつかは機械的に取得することが難しかったので諦めた)
  • サーバサイドのバッチ処理が重くて共用サーバに迷惑をかけたので、処理内容の見直しと、タイムアウト処理や高負荷時にバッチ処理をスキップする機能などを盛り込んだ(もう大丈夫なはず)
  • 細かな表示内容の調整

現在3700弱のgemがあり、それぞれのバージョンを保持しているので、17000弱の詳細情報を管理していることになります。

ごめんなさいな内容

仕様として諦めたものがあります。

  • どういうわけかspecファイルを取り出せないgemがあったけど、実害が無いだろうと思って諦めました。gem開いて左側にNO DATAと表示されていたら(かつ結構前にリリースされていた物だったら)諦めて自分でインストールして内容確認してみてください
  • 途中でRubyGemsの仕様が変わったらしく、以前は大文字小文字を認めていたものが、途中で小文字統一になったようです。よって、同じ内容のgemなんだけど別のgem名になったものがあります。(ANTFARMとantfarmとか、Bangkokとbangkokなど) 幸いdowncaseでまとめれるものばっかりだったのでgemspec.infoでは小文字側に合わせてあります。
  • 環境毎にコンパイルが必要なgemがありますが、gemspec.infoの設計上、全ての環境の分の情報は保持できないので、globして最初に引っかかったgem(windows用が多かった気が…)のspecファイルを使っています

まぁ、数は少ないので実害はないかと思います。

機能拡張予定

札幌Ruby会議01でいろんな方と話をする機会があり、不満点やアイデアを貰えたので機能拡張予定に盛り込みます。

  • gemをインストールする前に、そのgemがどんなものであるかを共有する、というgemspec.infoの方針に合致するので、最新gemからrdocを生成してサイトから見れるようにする予定です。
  • rdocもそうですが、specファイルの取得に関しても、現在は手元の開発マシンでデータ抽出を行って、サーバに転送していることが多いのですが、これをうまく自動化できないかなーと。と言っても、サーバのリソース制限がキツイのでマシンパワーが費用名処理は開発マシンで行うような流れになりそうだけど、データ同期が複雑になるしなぁとか考え中
  • githubなど、RubyForge以外のgemにも対応する。でも、ちょっと問題もあるので、詳細は下記参照
  • 開発はMacOSX10.5+Firefoxでしていて、他のブラウザは一度も開いたことがなかったので、ブラウザ互換性をもうちょっと頑張る。てか現状をIE7で見たらダメすぎて萎えた。githubでソース公開して、みんなに助けてもらうのがいいのかな。
  • うんちくでURL指定したときなどに、相手先のコンテンツを取得するタイミングでトラックバックできないかな? トラックバックURLを取得する標準的な方法ってあるんだろうか?
  • ブラウザ互換性の問題とか、オープンソースの強みを生かすには、早めにgithubとかで公開するのがいいかなーとか。(開発マシン・gitリポジトリ・サーバの3点間でcapistranoでデプロイできるんだろうか)
  • とかとか書き殴ると、自分で管理できなくなってくるので、retrospectiva使おうかと思うんだけど、どっかに無料で使えるサービスとか無いかな?

RubyForge以外のgemリポジトリへの対応に対する問題点

個人的にはgemで提供されている機能を一部改造してプラグインにしたり、別名で管理されたりなどしている現状にちょっと疑問を持っていて、本家にマージされて集約されれば便利なのに、そうならない問題への解決策として、githubのgem対応はとても便利だと思うし、gemspec.infoもすぐにgithub対応したいと思っています。

ただ、ちょっと検討してみるといくつか問題がありました。

gemspec.infoはgem名やその詳細を得るのにgemコマンドを使っており、

  • gem list -raコマンドで全gem名と全バージョンが取得できること
  • gem mirrorコマンド(またはrsync)コマンドなどで、インストールせずにgemファイルが取得可能なこと

の2つをクリアする必要があり(下記の理由によりgem sources -addは使いたくない)、またgithub特有の問題として

  • githubで提供されるgem名はユーザ名+ダッシュ+gem名の形で提供されることから、RubyForgeで提供されるgemと名前が重複する可能性がある このへん参照 InfoQ: GemのソースとしてのGitHub とRubyForgeの長所と短所
  • これを回避するため、gem sources -addコマンドでgithubのリポジトリを追加するのではなく、githubにあるgemをインストールしたいならgem install --sourceオプションを使って明示的に指定した方が良い→gemspec.infoとしてはインストールオプションの表示機能が必要かな
  • 他のgemリポジトリをサポートすることによる既存のデータベース構造への影響。特にGemやバージョンのIDとして文字列を使えるよう、friendly_idというプラグインを使っているので、ここをうまく回避できるかどうか

とか、おそらく他にも野良gemリポジトリはたくさんあるんだろうから、どこまでサポートして、それらにはどんな問題があるのか、とかとか。

gemspec.infoを使用|紹介|協力してくださった方々へ

いつもごひいきにありがとうございます。

moroさんにはrails勉強会で紹介していただいたとか。ありがとうございます。

gemspec.infoの開発自体はおいらの趣味がてらといった感じなので、クリティカルな物以外はこつこつやっていこうと思っているところですが、次の件については一人の力ではどうしようもないかなーと思うので、お手すきの時に助けて貰えると有り難いです。

  • ブラウザ互換性に関すること。今回jQuery使ってみたんですが、まだ慣れてないのと、元々ブラウザ互換性に対する知識が乏しいので、「こうじゃぼけー」と書いたパッチなんぞ送ってくださいましたら、即適用でございます。
  • まずはそのgemで何が出来るか、といった部分をまとめていく必要があると思います。gemspec.infoで言うところの、1行メッセージ(何/良/悪)とか、タグなど。じゃないと、同じようなgemが乱立すると思うので。自分でも分かる範囲で書いているんですが、ここを書けるのはある程度使い込んだ人だと思うので、自分の力だけでは50個ぐらいで限界のようです。(検索機能がまともに動かないとコンテンツを活かせないので、そこはおいらがんばりますです)
  • 最近のおいらがそうですが、gemに関する事をググるとき、検索結果から探している答えの候補をタブでポコポコ開きますよね。で、そのうち何件かが答えになると思うんですが、そのとき残ったタブのURLをgemspec.infoに登録しませんか? メモ代わりとして。たぶん同じ事を検索する人がいると思うので。本当は、ブックマークレットみたいなのがあればいいのかなぁと思ったり。(ブックマークレットのテンプレートないのかな?)