ホーム > アーカイブ > 2010-11
2010-11
少人数開発に役立つ5つのまとめ
- 2010年11月30日 10:00 AM
- 開発環境
ここ2ヶ月間で気になる記事がたくさん上がっていました。
特に少人数チームにおける開発に関する記事です。
昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。
そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。
また、せっかくなので新しいモノも取り入れたい。
こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。
どれもこれも、チーム開発で役立ちそうな記事です。
今日はこの3つの記事を中心に、少人数開発に役立つ様々な情報をまとめてみます。
体制を整えるための2記事
まず、少人数での開発がどんなモノか、そして何が必要かを知ります。
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろでは、少人数開発で気をつけなければならないことがまとめられています。
とても当たり前なことがたくさん書いてあります。
しかし、当たり前だからこそ、忘れがちなことです。
1. 丁寧に正しく作ろう
一つだけ選ぶとしたらこれ。これがすべてにつながってくる。スタートアップ企業にとって、スピードが大切というのは間違いないのだけど、目先のスピードのために、色々なことを犠牲にしてしまっていたことがあった。正しく丁寧に作ることが中長期で考えるとスピードにもつながる、ということを頭で理解しつつも、つい手を抜いてしまっていた。
まず、「今必要でないことはやらない – YAGNI 」ということを常に考えよう。そして、その上で「今必要」となったものは全力で丁寧に正しく作ろう。
2. 丁寧に正しく作れないなら既存のプロダクトを使う
丁寧に正しく作るのにはしっかりとしたリソースが必要。ただし、人やお金というリソースは常に限られているので自分たちが集中しないといけないところをしっかり決めよう。
独自フレームワークはやめよう
独自のフレームワークは正しく作れないならやめよう。「正しく作る」というのはメンテナンスとか含めて。もし作るなら専用のリソースを確保するぐらいできないと無理。片手間でフレームワーク作りとか無理。外部に向けて公開しても恥ずかしくないレベルのものを作れるようでない限りはやめたほうがいい。
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろより
この2つは、本当に気をつけながらやっています。
“今、何を作っているのか“、”本当に、自分がこれを作るべきなのか“を常に気をつけながら開発しましょう。
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろがマインド的な部分であったのに対して、複数人(2-3人)でウェブサービスを開発するコツではツール的な部分がまとまっています。
“開発環境には仮想化を使う“、”開発はチケットファーストで行う“など。
簡潔ですが、要点を押さえたわかりやすい記事です。
この2記事を読むことで、少人数開発に必要なマインドとツールがわかると思います。
私自身、この2記事を参考に環境を構築しています。
バージョン管理システムを一新するための2記事と2アプリケーション
バージョン管理システムにはgitを使います。
gitをチームで使う場合、問題となるのがブランチの運用です。
一から自分で考えても良いのですが、そのルールが熟れるにも時間が掛かる。
そこで、誰かが作ったルールに乗っかってしまいましょう。
そこでこの記事が役に立ちます。
この記事にはgitにおけるブランチの運用が、わかりやすくまとまっています。
チームのマニュアルとしても、十分に使えるレベルでしょう。
こういったルールを守るためには、ちょっとした仕組みも欲しいところです。
例えば、”masterブランチには直接コミット出来ないようにする“といった仕組みです。
この記事では、Redmineのチケットとコミットを連携させるためにmasterブランチへの直接のコミットを禁止するフックを紹介しています。
この記事で言っているトピックブランチは、A successful Git branching model を翻訳しましたのフィーチャーブランチのことです。
色々試してからですが、私もこのフックを導入しようと企んでいます。
gitに関連するアプリケーションも2つ取り上げます。
Gitoriousはgithubのコピープロジェクトです。
Webブラウザ上でGitリポジトリを管理できます。
開いた人は”githubを使えばいいんじゃない？“と思うでしょう。
ところが、このGitorious、オープンソースプロジェクトなんです。
つまり、自分のサーバにインストール出来る。
リポジトリの管理は結構面倒なので、GUIで直感的に操作できるGitoriousを入れると良いと思います。
TowerはMac用のGitのGUIクライアントです。
Gitを使っていてよく聞くのが、決定版のGUIクライアントがないことです。
その決定版GUIクライアントとして期待されているのが、このTowerです。
“期待されている”と書いたのは、残念ながらまだリリースされていないからです。
11月リリース予定なので、この記事と一緒にリリースされれば良いのですが…。
[追記]
記事を書いていたら、リリース告知がありました。
この記事が公開されるころには、リリースされているはず！
テストを自動化するための3記事
少人数開発では、人手が足りません。
テストチームなんていませんよね。
そのため、テストは自動化が基本になると思います。
Sereniumは、Webアプリケーションのテストを自動化してくれます。
これはすごい! Web案件必須 Seleniumを読めば、Sereniumの概要がわかります。
PHPUnit と Selenium RCで機能テストをやってみるを読めば、簡単にSereniumを導入できそうです。
さらに、毎日のテストを自動化するためにHudsonを入れます。
Hudsonはビルドやテストを定期的に実行し、その結果を管理するためのツールです。
日本Hudsonユーザー会も発足した「Hudson勉強会」活動報告にはUstreamの動画と共に、豊富な事例がまとまっています。
初心者のための簡単な紹介もありますよ。
また、RedmineとHudsonを連携するこんな事例もありました。
HudsonとSereniumを入れて、効率的にテストを実行しましょう。
チケット管理システムを正しく運用するための1記事と1冊
チケット管理システムといえば、RedmineかTracです。
ここではRedmineを取り上げます。
Redmine導入時にやってしまいそうなことが、よくまとまっています。
導入は簡単です。
しかし、適切に運用するためにはそのツールで使っている用語の意味を知ることが大事です。
これを読んでから、Redmineの運用を始めると、よりRedmineを活用できるでしょう。
さらに、この記事でも紹介されていますが、こんな本も出ています。
|
Redmineによるタスクマネジメント実践技法
|
今までRedmineに関する本はその導入の仕方や使い方がメインだったので、嬉しい一冊です。
アジャイル開発をマネタイズするための1記事
最後にちょっと毛色の違う記事を取り上げます。
私は基本的に受託開発をしていないのですが、とても参考になる記事です。
受託開発では”システム当たりいくら“が基本だと思います。
しかし、この記事を読んで”こういったビジネスモデルもあるのか“と目から鱗が落ちました。
もし、受託開発をする場合は、こういった形で仕事がしてみたいですね。
いかがでしょうか。
この記事は正直、素晴らしい記事に乗っただけの記事です。
ですが、”ここまで色々と情報が揃ってるのにまとめないのはもったいない！“と思い、この記事を書いてみました。
参考になれば幸いです。
1年間の技術的負債を返すために読んだ3冊の本
- 2010年11月29日 10:00 AM
- 開発環境
[この記事を読む前に]
タイトルに騙されて来た方はごめんなさい。
恐らく、知っていることばかりが書いてあると思います。
“3冊の本”もベストセレクションではありません。
“たまたま”選んだ3冊の本です。
それでも読んでくれる心優しい方はどうぞ、先にお進みください。
技術的負債は日々、返済していますか。
技術的負債って何？という方はこちらへ。
えー、正直、私は技術的負債が溜まっています。
お知らせメールを本格的に初めて1年が経とうとしています。
何も無い状態から、手探りで始めて今の状態までなんとか持って行きました。
この計画が立ち上がった当時(2年ぐらい前かな)、自分ができたのは、
- PHPが書ける(書けるだけ)
- サーバが少しわかる(cdとlsが打てるだけ)
これぐらいです。
ちょっと大げさですが、あながち嘘じゃない。
そんなこんなで、試行錯誤の毎日。
運営を始めるとさらに大変で、技術的負債がどんどん溜まっています。
やっと、機能追加も落ち着いてきたので、技術的負債を返そうという話が相方との間で出ています。
コードのリファクタリングを含め、開発環境を全面的に見直したいところです。
そこで、技術的負債を返すべく、勉強のために3冊の本を読みました。
今日はその3冊の内容にプラスアルファして、1年間で学んだことをまとめていきます。
そもそもなぜ、技術的負債が溜まったのか
私は新しいモノ好きです。
そして、気に食わないことはとことん突き詰める質です。
そんな性格から、モノを作っていると色々なことが気になってくる。
これはこれで、本当にいいのか。
これが頭の中に浮かぶともう止まらない。
これに追い打ちをかけるように、新しい技術や手法が次々と飛び込んでくる。
これを使えば、さっきの問題は解決するんじゃないか。
こんな毎日で、日々やり方を変えていきます。
そうすると残るのは、過去のやり方でやったコードや環境です。
確かに新しいやり方はしっくり来るし、とても心地良い。
しかし、”過去のやり方でやったところを直すには時間が掛かる“。
そもそも、現状のやり方で問題なく動いているところです。
これを直すには、気力と時間が必要です。
そして、”それじゃ後でまとめてやろう“という一言に甘える。
簡単に言ってしまえば、これが技術的負債の正体なんでしょう。
技術的負債を返して、負債を溜めないために
技術的負債を貯めない方法、その一つがアジャイル開発なんだと私は考えました。
TDDを取り入れた、スピード感のあるインテグレーション開発。
私はTDDを去年のCakeMatsuriから、試行錯誤で実践しています。
今まで個人的にTDDをやってきて気がついたのは、”TDDは技術的負債を返すための道具ではない“ということです。
確かに、TDDを実践すると気持良く開発を進めることが出来る。
しかし、TDDだけでは技術的負債は溜まっていきます。
TDDを実践する前よりはマシですが、それでも溜まっていく。
TDDはアジャイル開発の一部だと言うことです。
恐らく、TDDはアジャイル開発の手法と併せて、初めてその威力を発揮する。
そのリズミカルな開発サイクルに乗せることで、日々技術的負債を返していける。
そう考えたんです。
前置きが長くなりました。
これが、今回読んだ3冊の本です。
|
アジャイル・プラクティス
|
|
アート・オブ・アジャイル デベロップメント
|
|
バグのないプログラムのつくり方
|
この3冊の本から、私が重要だと思う点、そして今後実行すべきタスクをまとめてみます。
アジャイル・プラクティス
アジャイル・プラクティスはとても読みやすい本です。
アジャイル開発の入門には最適でしょう。
- 200ページの読みやすい厚さ
- 2500円という(技術書にしては)買いやすい値段
アジャイル・プラクティスはアジャイル開発の”スピード“とその”リズム感“を主眼において書かれています。
例えば、アジャイル開発の設計段階の解説では、こんな記述があります。
設計の出発点では、個々のメソッドやデータ型に注力する戦術的設計よりも、責務の観点から考えるクラス設計のほうがふさわしい。というのも、責務中心のクラス設計であれば、抽象レベルを高くしたまま、ゴール思考で考えることができるからだ。実のところ、CRCカードによる設計は、まさしくそのための手法だ。CRCカードによる設計では、クラスを次の視点から表現する。
ホワイトボード、スケッチブック、付箋紙は、素晴らしい設計ツールだ。複雑なモデリングツールは、気づきを与えてくれることよりも、集中力を削いでしまうことのほうが多い。
アジャイル・プラクティス 戦略的設計と戦術的設計(p52)より
付箋とホワイトボードが好きな開発者は数多い。
その理由がこれなんでしょう。
私自身、なんとなく理解していましたが、さらにその利用用途が明確になりました。
どうせなら、どでかいホワイトボードが欲しいな、とぼんやりと考えてみたり。
ホワイトボードはさておき、私たちの開発環境で必要なもの、それはこれです。
製品が使い物になるために必要な本質的な機能はどれなのかをユーザに聞いてみよう。その際には、話が脇道にそれないように気をつけよう。素敵だけども実装できるかどうかわからない機能の話に夢中になったりしないこと。また、想像しうる限り最高に魅力的なインターフェースを目指したりしないこと。
アプリケーションを早めにユーザの元に届けると、うれしいことがある。
アジャイル・プラクティス 短いイテレーションでインクリメンタルにリリースする(p72)より
アジャイル開発では、作成したソフトウェアのデモやデプロイまでが小さなサイクルの中にあります。
そもそも、この”ソフトウェアのデモ“が重要なファクターだと思います。
つまり、このデモの準備も自動化し、高速に行う必要がある。
お知らせメールは受託開発ではありません。
完全に自社開発・自社運用でやっています。
顧客に見せるデモという段階はありませんが、開発した機能をトータルテストする段階はある。
これをアジャイル開発におけるデモと置き換えることが出来ると思います。
現状、これが自動化されていません。
これは、やろうやろうと思ってやってこなかった技術的負債です。
必ず自動化して、開発サイクルを高速化しようと思います。
その他にTDDの進め方から、コードの書き方までアジャイル開発に必要な事項を幅広く取り上げてあります。
アジャイルについてまったく知らないなら、この本から読むことをオススメします。
事実、アジャイルを知らない私が、とてもスラスラと読むことが出来ました。
アート・オブ・アジャイル デベロップメント
アジャイル・プラクティスの次に読んだのはアート・オブ・アジャイル デベロップメントです。
これはアジャイル・プラクティスの内容を詳細にしたような本です。
チームにアジャイルを適用するために、必要な事項がまとめられています。
例えば、アジャイルを始めるにあたって、チームの規模は初めに気にするところだと思います。
アート・オブ・アジャイル デベロップメントには以下のような記述があります。
もちチームのプログラマが4名未満だったら…
それでもXPプラクティスの多くはまだ適用できるが、ペアプログラミングは難しくなるだろう。この場合、そのプログラマが高品質なコードを書くのに情熱を持ち、誠実であるなら大丈夫だ。こうした情熱があれば、XPの技術的なプラクティスを規律を持って適用できるだろう。
常に同席してくれるオンサイト顧客を持つのにも苦労するかもしれない。代わりに彼らの近くに席を並べよう。そうすれば必要なときに彼らの関心を引くことができる。
アート・オブ・アジャイル デベロップメント XPを導入する(p50)より
プログラマが少ないチームだと、各人のモチベーションが重要だと言うのは納得出来ます。
二人で開発していると、チームとしてのモチベーションがほとんど存在しません。
個々のモチベーションが重要です。
二人三脚で一人が走らないとまったく動きませんよね。
そんな感じです。
やはり、小さなチームでやる以上、お互いの理解と同意が必要ですね。
その他に、アート・オブ・アジャイル デベロップメントで参考になるのはコーディング規約に関する話です。
私はかつてプログラマ4名からなるチームを率いていた。書式に関して、彼らは大きく異なるアプローチをとっていた。コーディング標準について議論するときに、私はカッコとタブに関して3つの異なるアプローチのカタログを作った。それぞれのアプローチには熱心な支持者がいた。私はそんな議論にはまり込みたくなかったので、好きなスタイルを使ってもいいよと言った。
結果は予想通りだった。コードの書式には、3つの異なるアプローチが使われていた。1つの短いメソッドの中に2つの異なるインデントが使われているのを見たことがある。
何が私を驚かせたか分かるかい？そんなにひどくなかったんだ。確かにレイアウトは見苦しいし、私は一貫性がある方が好きだ。それでもコードを読むことができた。結局、書式以外のコーディング標準のほうがもっと重要だったんだ。
アート・オブ・アジャイル デベロップメント コーディング標準(p138)より
これも長くコードを書いていると分かってきます。
コードは美しく書くのではなく、明瞭に書く。
明瞭というのはコードの意味が明瞭ということ。
例えばこんなコードです。
$artiles = array(
'title1',
'title2',
'title3');
foreach($articles as $no => $article) {
printf('No.%s : %s', $no, $article);
}
$vars = array(
'title1',
'title2',
'title3');
foreach($vars as $key => $value) {
printf('No.%s : %s', $key, $value);
}
明らかに、前者よりも後者が分かりやすいですよね。
明らかに、後者よりも前者が分かりやすいですよね。
レベルの低い例で申し訳ないのですが、これは本当に大事です。
この話がメソッド名やクラス名に繋がってきます。
PHPやPython、PerlやCというのは、全てプログラミング言語です。
言語なんです。
つまり、わかりやすい文章を明瞭に書く必要がある。
それを先程の引用から考えさせられました。
アジャイル・プラクティスを読んで生まれる、”じゃあ、実際にはどうするの？“という疑問に答えてくれる一冊です。
バグがないプログラムのつくり方
これはEclipseを使ったJava開発に向けて書かれた本です。
ですが、テストを書く上で必要なtipsが書かれた本でもあります。
個人的には”6章 テスト駆動開発のエトセトラ“だけ読めば十分だと思います。
6章には、TDDにおける犯しがちなミスとその解決策がまとめて載せてあります。
賢人さんたちは、その仕様変更や機能追加の際には、必ず先に従来のコードをリファクタリングしてから始めるようにしていました。そうすることで、機能追加する前に従来のコードに対する理解も深まり、追加後のリファクタリングできそうなポイントも見つけることができます。
愚痴さんの参加しているプロジェクトもTDDを採用しており、たくさんのテストコードがあって、すべて成功しています。ここまでの状況は、賢人さんのプロジェクトと同じです。しかし愚痴さんは、テストコードのメリットは何度も実行できることだけだと思っていたので、テストコードの見直しは行いませんでした。
賢人さんのところは、テストコード自体のわかりやすさを保ったまま、ソフトウェアを大きくすることができました。仕様変更や機能追加の際に、テストコードから見直す場合にも、わかりやすいのは非常に助かりました。
愚痴さんのところも、機能追加の際にテストコードは非常に役立ちました。しかし、仕様変更の際に従来のテストコードを見直す必要がある場合には、時間がかかるようになってしまいました。
バグのないプログラムのつくり方 テスト駆動のエトセトラ(p144)より
私も面倒臭いがために、この中の愚痴くんと化しているところがいくつかありました。
わかってはいたけど、修正できない。
まさに技術的負債ですね。
技術的負債を返すために、まずはテストコードのリファクタリングから始めましょうか。
買うのはちょっとという人は、立ち読みでも良いと思います。
6章を少し読んでみてください。
テストを見直すきっかけになります。
まだまだ得たものはたくさんあるのですが、記事に書けるのはこんなところです。
最後に個人的タスクをまとめておきます。
必ず実行して、技術的負債を完済します。
- 必ず実行するタスク一覧
- テストコードのリファクタリング
- コーディング規約の見直し
- コーディング規約チェック自動化
- テスト自動化
- デプロイ自動化
- デモ環境へのデプロイ自動化
最後に
最近、技術書に関する記事が盛り上がっていましたね。
人それぞれ、各書籍に対して色んな意見があると思います。
とりあえず、立ち読みで、あるいは図書館で借りて読んでみてはどうでしょうか。
自分にとって役に立たないのであれば、読まなければ良いんですから。
(少しの時間が取られるかもしれませんが、良書にあったときに得られるものと比べたら大したことはないでしょう。)
私が今回読んだ3冊も、通読なんてしていません。
何を学びたいか、何を得たいかだけ意識して、自分の欲しいところだけ読みました。
自身のレベルによって学べるところは様々なんだから、読む本は自分で決めましょう！
これが言いたかっただけで、”最後に”を書いてみました(^^;
英語を勉強するために行った環境改善まとめ
- 2010年11月14日 12:00 AM
- Lifehacks
毎日、更新されるブログの中で人気が高いのは”英語“というキーワードです。
なかなか、勉強できないんですよね。
仕事によっては必要性が薄く、触れる機会も少ない。
しかし、”英語が出来れば面白いことができるんじゃないか、人に自慢できるんじゃないか“と期待してこういった記事を開いてしまう。
- 英語が話せるようになる5つのtips
- 1週間でTOEICが800点になった件について
- 無料で出来る英語勉強法
色々な勉強法があって良いと思うのですが、結局、どのやり方でもそこまで効果は変わらないと私は考えています。
恐らく、語学を学ぶ上で最も重要なのは”総時間“でしょう。
どれだけその言語に触れていたか。
どれだけその言語を”自然に”理解できたか。
こういった前提で、”英語をどう勉強するか“を考えてみました。
それは単純で、”自分が一番触れているものを英語化する“という勉強法を思いつきました。
“自分が一番触れているもの”、それはMacBookとWebです。
ここまで来れば、この記事の内容がわかりますね。
そう、今日は普段使っているMacBookとWebサービスを英語化するまとめです。
MacBookを英語化する
まずは、MacBookを英語化します。
日本語のシステム環境設定
言語とテキスト
日本語の優先度を上に設定した言語とテキスト
後は再起動するだけでMacBookが英語になります。
英語のシステム環境設定
日本語で長年使っている方は、これだけで新しい発見があると思います。
様々な場面で出てくるダイアログボックスのメッセージを読んでみてください。
“日本語ではこう書くけど、英語ではこう書くのか！“と新鮮なはずです。
最も使うGoogleを英語化する
次はGoogleを英語にします。
日本語のGoogleトップページ
表示設定
英語のGoogleトップページ
これで常に英語でGoogleが使えます。
Googleを英語にしたことで大きく変わったのは以下の2点です。
- Google Instant Searchが使える
- 段落の空白が違い、日本語が見づらい
Instant Searchも地味に嬉しいのですが、英語を勉強する上で重要なのは2つ目です。
英語のGoogleは英語を基準として考えられているために、日本語で使ったときに表示が見づらいんです。
見づらいと何が起きるか。
“英語で検索してみようかな“、あるいは”英語で検索しないと！“という気持ちになります。
大抵の人はプログラミングをしているときに、構文や関数名を忘れてググると思います。
このような簡単な検索をするときに、”英語でやってみよう“という気持ちを思い出させてくれます。
さらに”検索する“ということは、”英単語を調べて打ち込む“という行為です。
英語検索は、”英単語の暗記“にも優れています。
Googleの英語化、おすすめですよ！
ソーシャルサービスを英語化する
最近は日本でも海外のサービスが流行り、多くの人が使ってます。
エンジニアがよく使うソーシャルサービスと言えば、
でしょう。
この3サービスは全て日本語に対応しているのですが、これをあえて英語で使います。
設定はどれも簡単です。
この記事を呼んでいる読者は、説明するまでもなく設定できると思います。
ですが、記事を豪華に見ｒｙ、
英語設定のスクリーンショットを載せておきます。
github
RSSで英語のフィードを購読する
Google Readerに英語のブログやソーシャルブックマークのフィードを追加します。
しかし、Google Readerは日本語のブログを購読するのにも使っています。
登録済みの日本語フィードと新しく追加する英語フィードを混ぜると、
日本語のフィードばかり読んでしまい、英語のフィードを読み飛ばす
という現象が起こります。
これじゃ、せっかく登録した英語フィードが無駄になる。
そこで、Google Readerのフォルダ機能を使います。
英語と日本語のフィードをプレフィックスで分けて管理します。
Google Reader
プレフィックスを付けなくとも、単純に“英語”と”日本語”のフォルダ名で区別できます。
しかし、決まったルールがあったほうがわかりやすいので個人的にはこの形をとっています。
自分の分かりやすい名前を付けてください。
これで、英語フィードを登録する準備ができました。
私は以下の3種類のフィードを登録しました。
- ソーシャルブックマーク
- 趣味ブログ
- 技術ブログ
ソーシャルブックマーク
ソーシャルブックマークは有名な以下のサイトを登録します。
これに加えて、Instapaperのフィードも追加。
日本の”あとで読む“に当たるサービスです。
この3種類を登録すれば、興味が沸く記事が自動で流れてきます。
“読んでみたい！“と思う記事が多いので、英語を読むモチベーションも高まります。
趣味ブログ
私は趣味ブログとして、ライフハックに関するブログを登録しました。
こういった趣味ブログを探すには、Google Readerのフィード検索機能を使います。
Google Readerのフィード検索
ここに自分の趣味のキーワードを入れて、適当に登録数の多いブログを探します。
Google Readerのフィード検索結果
先ほどのソーシャルブックマークのフィードと同じですが、自分の興味が沸くフィードを登録すると良いと思います。
技術ブログ
最後に仕事用の技術ブログを登録します。
技術ブログは少し前に、こんな記事が上がっていたので参考にします。
ここから、自分の興味が湧きそうなブログを選んで登録します。
ここでもやはり、”自分の興味が沸く“を大切にします。
記事に対するモチベーションが低いと、読めないですからね。
さらに、プラスアルファで始める
さらに、プラスアルファで個人的に始めたことを。
洋書の読書
毎日、寝る前に洋書を少しずつ読んでいます。簡単な物語から初めて、たくさんの洋書を読んでみようかと。洋書の多読はこちらの記事が参考になります。
ちなみに、私は今この本を読んでいる途中です。
|
The Curious Incident of the Dog in the Night-Time
|
映画のリスニングとシャドーイング
映画をMP3に変換して、常に聞いています。
同じ映画を聴き続け、耳を英語に慣らすためです。
もう少ししたら、シャドーイングも再開しようかと。
このあたりの話は、この本が参考になります。
|
英語は絶対、勉強するな!―学校行かない・お金かけない・だけどペラペラ
|
idea x ideaさんで紹介されていたこのソフトを使うと映画を簡単にMP3に変換できます。
11月15日まで無料だそうなので、すぐにダウンロードしちゃってください。
どうでしょうか。
参考になりましたか？
英語は1ヶ月やそこらでマスター出来るものではないと思っています。
少しでも早く初めて、少しでも多く英語に触れる。
できるだけ自然な形で、単語の使い方や意味を学ぶ。
“これがやっぱり大事かな”と思い、こんな記事を書いてみました。
それにしても、いい時代になりましたね。
ちょっと設定するだけで、英語環境が手に入るんですから。
よく考えれば、Macで使っているアプリケーションのほとんどは”英語がベース“ですからね。
これを利用しない手はないでしょう。
これだけでは英語を話したり書いたりは出来ないと思いますが、英語を勉強する取り掛かりには良いでしょう。
英語に対する障壁を下げて、徐々に学んでいきましょう。
さて、英語勉強第二弾、がんばるぞー！
(ちなみに、私の第一弾は失敗に終わっていますｗ)
日本独特のエラーメールをも解析してくれるBounceHammer
- 2010年11月8日 12:00 AM
- Linux
仕事でメールサーバを構築したことはあるでしょうか。
最近のWebサービスではメールを送信する機能がデフォルトで求められることが多いですよね。
例えば、流行りのWebサービスでも…。
どのWebサービスでもメールを使っていますね。
その結果、あなたのメールボックスはゴミ箱になっていくのです。が、それは別の話。
このようなWebサービスのメールシステムを構築する上で必要なのは、Postfixやsendmail、qmailといったMTAだけではありません。
送ったメールを送った後も責任持って処理すること。
これが必要です。
今回はこの処理を手伝ってくれるオープンソース”bounceHammer“を紹介します。
bounceHammerとは
bounceHammerはバウンスメール(エラーメール)を処理するために作られたオープンソースです。
Cubicroot Co. Ltd.が開発/管理しています。
Perlで書かれており、YAPC::Asia Tokyo 2010で知った人も多いのではないでしょうか。
bounceHammerを使うとどんなことが出来るのか。
最も一般的な使い方はこれでしょう。
存在しないメールアドレスにメールを送った場合に返ってきたバウンスメールを解析、それをWebサービスに通知する。
Webサービスではメールアドレスが存在しないことをユーザに通知し、メールアドレスの変更を促す。
このシステムを、bounceHammerを使うことで簡単に実現できます。
何が良いのか
bounceHammerが素晴らしいのは、”導入するだけでGUI付きのバウンスメール解析システム“が手に入る点です。
bounceHammerの管理画面
バウンスメール対策で面倒なのは、”複数のバウンスメールが存在すること“です。
バウンスメールはMTAに依存するために、様々なメッセージが存在します。
さらに厄介なことに、日本ではメールの主流である”携帯電話の3キャリア“が返すバウンスメールを考慮する必要があります。
こういったバウンスメール全てに対応するためには、日々の管理が欠かせません。
どんなメールが返ってきて、どのメールを”不通“と判断するのか。
こういった管理をしてくれるのがbounceHammerです。
./configure ./make ./make installするだけで”GUI付きのバウンスメール解析システム“が手に入るんです。
素晴らしいと思いませんか。
私が優れていると思うのは以下の点です。
- 簡単なインストール
- 日本語の公式ドキュメント
- Perlを使ったシステム
- 機能の分離
- バウンスメールの詳細な分類
一つ一つ解説していきましょう。
簡単なインストール
先程述べた通り、インストールは一般的な”./configure ./make ./make install”です。
環境によってはPerlのモジュールが必要になりますが、それは./configureでインストーラが指示してくれます。
その場合は、CPANを使って指示されたモジュールをインストール、再度./configureすれば良いだけ。
インストール自体は1時間で終わるでしょう。
その後、必要に応じて、cronとApacheの設定が必要です。
メールサーバを構築できるエンジニアなら、これも簡単に終わるでしょうね。
日本語の公式ドキュメント
bounceHammerは”日本純正のオープンソースソフトウェア”です。
そのため、日本語のドキュメントが用意されています。
これがシンプルでわかりやすい。
メールシステムの全体図も用意されています。
これに沿って構築すれば、迷うことはないでしょう。
Perlを使ったシステム
bounceHammerはPerlで書かれてます。
つまり、うまく動作しなかったり、動作がわからない部分はソースコードを簡単に参照できます。
私自身、インストールの途中でソースコードを参照しました。
Perlは触ったことがなかったのですが、簡単に読み解くことが出来ました。
そして、2時間程度ハマっただけで、問題を解決することが出来ました。
問題があった場合にPerlで書かれているために、自分で原因が特定できます。
bounceHammerを使うエンジニアはそのほとんどがWeb系でしょう。これは地味に嬉しい。
機能の分離
bounceHammerは、綺麗に機能が分離されています。
先程、”バウンスメールをGUIで管理できる”と書いたのですが、実はこれ、必須ではありません。
GUIの管理機能を省いて、解析機能だけを活用することができます。
それをやりたい場合はこのコマンドを使うだけ。
cronに設定するなり、毎日手打ちするなり、それだけでOKです。
bounceHammerが毎日来るバウンスメールを解析、分類してくれます。
分類したメールはあなたのWebサービスに取り込ませて、あとはご自由に。
バウンスメールの詳細な分類
デフォルトではバウンスメールが以下のように分類されます。
- 不明なホスト(hostunknown)
- 宛先不明(userunknown)
- メールボックスは移動した(hasmoved)
- 発信者アドレスによる拒否(rejected)
- フィルターによる拒否(filtered)
- メールボックス一杯(mailboxfull)
- メールの量が限界(exceedlimit)
- メールサーバのディスクが一杯(systemfull)
- メールサーバはメールを受け取らない(notaccept)
- メールが大きすぎる(mesgtoobig)
- セキュリティ上のエラー(securityerr)
- 一時停止中(suspend)
- メーラーエラー(mailererror)
- システムエラー(systemerror)
- メール形式のエラー(contenterr)
- 配送時間切れ(expired)
- エラー理由決定保留(onhold)
ここで注目して欲しいのは”filtered“です。
つまり、デフォルトで携帯のフィルタに引っかかったことまで解析してくれます。
bounceHammerの開発者あずまさんからコメントを頂きました。
bounceHammerでは、以下のフィルタリングの種類までは判断できないそうです。
- ドメイン指定受信によるフィルタ
- URLフィルタ
ただし、URLフィルタは”アダルトサイトなどの有害なURL“をフィルタリングするもの。
そのため、通常のサイトであれば、filteredとして分類されるのは”ドメイン指定受信“によるものと考えて良いそうです。
詳しくはコメントをどうぞ。
デフォルトの設定で十分に使える。
bounceHammerからは、そんな印象を受けます。
ちょっと気になるのは
と、ここまではbounceHammerの良い点だけを取り上げてみました。
これだと、bounceHammerの回し者だと取られかねないので(そんなことはない？^^;)、気になった点を一点だけ。
- 言語レベルでエラーが出てくる
何か問題が発生したときに、Perlのエラーが出てきます。
自分で問題をトレースするには良いのですが、正直パッと見で何が起きたのかわからないのが辛いところです。
私がたまたまレアなエラーに当たったのかもしれませんが…。
ASPと比較、それにちょっとした考察
メールの大量送信はASPを利用するのが一般的だと思います。
ただ、こういったASPは料金が高い上に、作ったWebサービスと連携しにくいというデメリットがあります。
しかも、細かく送信設定ができなかったり、そもそも上記のページだけではどんな仕様かわからなかったり。
そもそも、自社で管理運営するメールシステムと比べて、これらのASPを使うメリットはなんでしょうか。
- システムのメンテナンスがいらない
- メールの大量送信時もメールの遅延がない
この二点でしょう。
“システムのメンテナンスがいらない“はクラウドのメリットなので、ここでは置いておきます。
“メールの大量送信時もメールの遅延がない“は以下のシンプルな対策を講じることで、回避できるでしょう。
- メールドメインの逆引き設定
- IPアドレスと時間あたりのメール送信数
- バウンスメールの適切な処理
“メールドメインの逆引き設定“はDNSの設定ですね。
これは誰でもできる。
“IPアドレスと時間あたりのメール送信数“はMUAの設定ですね。
プログラムとサーバの設定次第です。
これも誰でもできます。
“バウンスメールの適切な処理“はバウンスメールの解析が必要です。
自分でメールの大量送信システムにあたり、これが一番のネックではないでしょうか。
相手のMTAがどんな動作をするのか。
これを把握するためにはある程度のノウハウが必要ですから。
しかし、今回、これを行ってくれるbounceHammerがリリースされました。
bounceHammerを使えば、1日あればバウンスメールを解析する環境が手に入ります。
そして、bounceHammerはオープンソースソフトウェアです。
つまり、様々な人に使われ、バウンスメール解析のノウハウが溜まっていきます。
つまり、ASPにおける”メールの大量送信時もメールの遅延がない“というメリットは、bounceHammerが公開されたことで、ほとんどなくなったのではないでしょうか。
自分で”メールの大量送信時もメールの遅延がない“システムを簡単に組めてしまうんですから。
私たちみたいなスタートアップは特に
スタートアップでは、”お金はないけど時間はある“という状況がほとんどでしょう。
つまり、自分たちの時間を使ってでも、”お金を節約したい“という状況です。
さらに言えば、Webサービスを使ってくれている人も少ないのに、コストの掛かるASPを導入するわけにはいかない。
メールサーバはさくらのVPSで済ませたい訳です。
bounceHammerとPostfixを使えば、さくらのVPSでメールサーバを立ち上げられます。
あとはPHPやPython、PerlといったLLな言語で簡単なMUAを作ります。
これで、スタートアップの”メール遅延のないメールシステム“の完成です。
あとは時間あたりのメール送信数を調整してやればOKです。
このあたりの話は少しググると、情報は少ないですが出てきます。
どうでしょう。
bounceHammerの素晴らしさが理解してもらえましたか。
私自身、このようなオープンソースソフトウェアが欲しいと思っていました。
メール送信においてバウンスメール対策は重要であるにも関わらず、あまり情報共有されていませんでした。
ならば、オープンソースにして共有したらどうか、と。
CakePHPのEmailPluginに組み込もうと思っていたのですが、こんなのがあるなら全然いらないでしょ！となっちゃう訳ですね(苦笑)
EmailPluginにはbounceHammerのYAMLを読み込む機能を導入しようかな。
良いソフトウェアだと思うので、みんなで使ってブラッシュアップしていきましょう。
bounceHammerをよろしくどうぞ。
あ、最後に決して私はbounceHammerの回し者ではないですよ。
オープンソースの回し者ではありますが。
勉強会でタイムラインを垂れ流しにするTweet Search Stream
- 2010年11月2日 12:00 AM
- Service
Google日本語入力 TechTalk 2010で教えて頂いた”Tweet Search Stream“を紹介。
簡単にいえば、TwitterのTLを垂れ流しにするだけなのですが、これがかなりシンプルで地味に活用できそうです。
特に勉強会で！
tweet search streamとは
Tweet Search Streamは@gimiteさんが作られたWebアプリケーションです。
サイトから引用します。
This is real time Twitter search using Twitter Streaming API. New tweets are automatically shown in a few seconds after posting.
“Twitter Streaming API“を使ったTwitterのリアルタイム検索ですね。
サイトを開いてみると分かるのですが、ものすごい勢いでツイートが更新されていきます。
これだけで分からないのが、その更新の反映速度です。
つまり、自分がつぶやいた内容がどの程度でこのTweet Search Streamに反映されるのか。
これを見てください。
タイムラグがほとんどないのがわかります。
これはすごい！
勉強会で活用する
先程の動画を見ていただいた方は分かると思います。
“Tweet Search Stream“の臨場感は半端ではありません。
これをフルスクリーンで、会場のモニタに写してやる。それで、即席のTwitterリアルタイム実況環境が出来上がり。
盛り上がること間違いなし。
自分のつぶやきが即座に会場のモニタに反映されるのだから、呟きたくもなりますよね。
Google日本語入力 TechTalk 2010では常に会場のモニタに映し出されていました。
そのモニタを見ながらセッションの質疑応答をしたり、LT参加者の募集をしたり、とかなり活用されていましたよ。
Twitterはこの臨場感が堪りませんよね。
それを会場で共有できるのだから、使わない手はない。
自分で実装する
エンジニアならこういうツールを知れば、自分で作りたくなるもの。
あるいは、どうやって実装しているのか気になりませんか。
実は、Tweet Search Streamのソースコードが公開されています。
公開してくれた@gimiteさんに感謝！
Rubyで書かれていますが、本体のソースは500行ぐらい。
Rubyを書いたことがない人でも、ちょっと調べながらコードリーディングできそうなレベルです。
(私自身、Rubyを書いたことがないのですが(笑))
PHP Matsuriに行ったときから、私のタスクボックスに
“Twitter Streaming APIを調べて、遊ぶ。”
が存在し続けているので、ちょうど良い機会かもしれません。
Tweet Search Streamを見ながら、私も何か作ってみます。
技術的にも、ツールとしても興味がそそられるモノがあったので紹介してみました。
是非、勉強会に、Twitter Streaming APIの参考に、とTweet Search Streamを活用してみてください。
ホーム > アーカイブ > 2010-11
- エキスパートPythonプログラミング読書会 第二期 07の募集を開始しました！ http://t.co/DuVQ32jM #expertpython 2 days ago
- 受付を撤収したので、遅れてくる方は @sanojimaru か、 @tfmagician まで声をかけてください。 #expertpython 3 days ago
- http://t.co/e4N59JH3 4章ですね、募集ページを修正しました。 #expertpython 3 days ago
- More updates...
気になるニュース- 無印良品の高度なFacebook連携がさすがだと思った件 « Looops 直人の備忘録
- Node.jsがどうして注目されているのか、もしくはどうして他のサーバサイドJavaScriptはスルーされているのか - id:anatooのブログ
- 0から始めるiPhoneからのWordPress更新術。第9回 終わりに。一連の流れ ...
- shell.vim 0.9.6 -- Improved integration between Vim and its environment (fullscreen, open URL, etc)
- Cakephp auth refresh websites and posts on cakephp auth refresh
- さよなら、iPhone。 日本でも訴訟されて発売されるGalaxyS2の凄さがわかる動画 alpha device
- フィードからの情報をデスクトップ通知してくれるChrome拡張機能「RSS Alert」
- PHPとアジャイル開発の勉強会を開催しました | 48JIGEN
- レノボ、Android 採用の ThinkPad タブレットを今夏発売へ。Windowsタブレットは年内
- 致命的すぎるバグがgithubで話題 « A-Listers
