steps to phantasien t(2007-06-01) ChangeLog の作法 つづき
Subversion の開発者が ChangeLog について面白い記事を書いている. 記事の要旨はこうだ: ChangeLog (Subversion なので commit log) を書くのは面倒だよ, メーリングリストもあることだし書かなきゃダメ? ってよく訊かれる. 書きましょう. バグトラックもあるけど, 書きましょう.これらのツールは補完しあっている. メーリングリストはノイズが多いし, 変更を特定するには情報が足りない. バグトラックはバグの記録がメインだからコードの話を細々書くのは邪魔になる. 変更については ChangeLog に書くのがいい. プログラマは ChangeLog を読む. 記録を検索して, どの関数に何が起きたかを調べるものだ. この類の記録は ChangeLog を読まないとわからない. 逆に ChangeLog を書く時は, それを特定できるように省略
holidays-l開発ブログ - Perl::Criticでコーディングスタイルを統一
Perl::Critic - Critique Perl source code for best-practices. - metacpan.orgをコーディングスタイルを統一するために使っています。 （実際には字面としてのコーディングスタイル（コードレイアウト？）はPerl::Tidy - metacpan.orgが担当しているわけですけども、ここでは「use strictを入れる」「PODを付ける」なども含めてコーディングスタイルと言ってます） コーディングスタイルに唯一絶対的に正しいなんてものはないわけで（だから宗教論争にもなるわけで）、機械的に統一することで揉め事はなくなります。 しかしその時に.perlcriticrcなんかを使ってコーディングスタイルをデフォルトから変更してしまうと元も子もありません。 .perlcriticrcに何を設定するかで揉めますし、例えその時に揉めな
プログラマの思索: RubyよりもJavaが好きな理由
最近、Ruby関西に行ってRubyの勢いを感じている。 そんな時に、Javaの最近の動きを聞く機会があった。 Java6やSeasarの話を聞くと、JavaがC#やRailsの影響を受けているように聞こえた。 でも、話しているうちに、「やっぱりRubyよりもJavaが好きなんだ」と気づいた。 その理由は、「JUnitのようなテスト駆動ツールが揃っている」点に尽きる。 そこで「テスト駆動の観点から眺めたJavaの利点とプログラミング思想」について考察してみる。 【１】テストを意識するとメソッドの行数が自然に短くなる プログラミング初心者のプログラムを見ると、行数がやたらと長く、長いプログラムを書き上げた後からデバッグし始める。 だから、いつまで経っても動かない。 プログラミング中級者になると、行数は長いままだが、少しずつ書いてはプリント出力してデバッグで動作を確認し始める。 この
今日は楽しいバグ修正の日 : 小野和俊のブログ
昨日でこのところ取り掛かっていた大きな仕事が一段落したので、 今日からは待ちに待ったバグ修正の作業を始められる。 この1ヶ月、私はバグ修正がしたくてしたくてたまらなかった。 今朝は出社してすぐにバグレポートの一覧を表示して、 これは早く直さないとまずいな、とか、これはちょっと後でいいかな、とか、 レポートの内容を見ながら優先度順にバグを並び替えていく。 これからこれらのバグが次々に修正されていくのだと思うと、 もうこの時点でワクワクしてくる。 新しいソフトウェアのアイデアを考えるのは大好きだし、新機能を実装するのも大好きだ。 でもバグ修正には他の作業にはない独特の快感がある。 新しいソフトウェアを開発するのは見た目にも派手だし、世間の注目を集めやすい。 それに比べると既存のソフトウェアのバグ修正というのは地味で注目されない作業だ。 だが、バグ修正は確実に誰かの役に立つ。 もちろん、自分の考
Six Apart - Tech Talk Blog: Perl モジュールの作り方
こんにちは。TypePad Engineer の重田です。 今年も YAPC::Asia Tokyo の季節がやってきました。今回も豪華メンバが参加するのでとても楽しみですね。 さて今回はYAPCにちなんでPerlモジュールの作成方法をご紹介します。 準備 Perl プログラマのバイブルである Perl Best Practices の Chapter17: Modules の Refactoring の冒頭で Damian Conway が言っています。 Place original code inline. Place duplicated code in a subroutine. Place duplicated subroutines in a module. さあ皆さんもそろそろ車輪の再発明に別れを告げてモジュール作りをはじめてみませんか？ h2xs 少し前の書籍などでは h2
steps to phantasien t(2007-02-18) 最近読んだ本: The Apache Module Book
現実逃避で少し Apache のソースを読んでいた. その資料探しにぐぐっていて発見. なかなかよく書けていた. 満足. (表紙のぞく.) 500 ページくらいあって身構えるけど, なぜか巻末に HTTPの RFC やら ASF ライセンスやらが付いていて 150 ページくらい水増しされていた. 実際は 350 ページくらい. コードも多く, 手軽に読める. まず Apache のアーキテクチャを概観し, APR, モジュール基本, コンテンツ生成, ヘッダ書き換え, 認証, フィルタ, 設定, デバッグ技法...とつづく. 新しい本だけあって Apache 2.2 の話題もある. けっこう網羅的な気がする. (気のせいかも知れない. 網羅されてない話があってもわからないし...) 実のところモジュール用にどんな API があるかはソースを持ってきて ヘッダや実際のモジュールを眺めればだい
mizzy.org : デプロイツール Archer #0
デプロイツール Archer #0 Posted by Gosuke Miyashita Sun, 11 Feb 2007 18:35:29 GMT id:tokuhirom さん作のデプロイツール Archer を最近使い始めたのですが、これがすげーいいっす。 で、この週末は更に便利に使えるように、Archer 用のプラグイン書いたりしてました。 Archer::Plugin::SVN::Log Archer::Plugin::SVN::Diff Archer::Plugin::SVN::Update Archer::Plugin::Rsync Archer::Plugin::Shell global: work_dir: /home/miya/work dest_dir: /home/miya/assurer tasks: init: - module: SVN::Diff - mod
なんちゃって個人情報
なんちゃって個人情報は「Generator of the Year」にて【便利賞】を受賞いたしました！！ 投票して下さったみなさま、本当にありがとうございました。 今後もどんどん使ってやって下さい。 プログラム等に使えるかもしれない個人情報のテスト用データを作成できます。特に説明が必要なものでもないので、とりあえずやってみていただければわかると思います。 念の為書いておきますが、生成した偽個人情報により発生したいかなる損害も当方は一切関知しません。たまたま名前が実在の人物と同姓同名になってしまうかもしれませんし、特に電話番号や携帯については実際に使われている番号と重なることがありますから、扱いには十分注意して下さい。 何かご要望とかありましたらお気軽にブログまでコメント下さい。 HTML シンプルなHTMLのテーブルで出力します。 XML ルートを<records>、各レコードを<reco
デモではものができあがっているように見せない
Kathy Sierra / 青木靖 訳 2006年12月27日 (アルファ版のような)開発中のものを私たちが世間や、クライアントや、ボスに見せるときには･･･彼らの期待のレベルを設定することになる。これは3通りの方法でやることができる。磨き上げられたモックアップで幻惑するか、プロジェクトの現状に合ったものを見せるか、ほとんどできていないものを見せながら順調に進んでいるから「信用しろ」と言っていら立たせるかだ。 結論を言うなら: どれくらい「できている」ように見えるかは、実際どれくらい「できている」かに合わせるべきだ。 ソフトウェア開発者はみんなそのキャリアにおいてこのことを何度も思い知ることになる。しかしテクニカルライターもまた、デスクトップパブリッシングツールによって同様の問題に直面する——フォントやレイアウトが完璧に仕上げられたドラフトを誰かに見せるなら、その人はあなたが考えるよりも
clmemo@aka: Emacs で C 言語プログラミングを始める人へのイントロダクション
Emacs エディターで C 言語のプログラムを書く人向けに、入門用の解説がないように思う。そこで、知っておくと便利な機能をまとめてみた。 読者は、Emacs の操作とカスタマイズが最低限できる人を対象にしている。つまり、C-x C-f といったショートカット・キーが使えて、.emacs の設定ファイルがいじれる人。各機能について、基本的な使い方とその効果、あと最低限の設定について書き出した。 目次 ソースの色付け インデント アラインメント コメント info マニュアル スペル・チェック タグ・ジャンプ 関数名の補完入力 コンパイルとエラー行ジャンプ ChangeLog ファイル 1. ソースの色付け Emacs は、C 言語のソース・ファイルを解析して、if や for といったキーワードに対して、自動で色を付ける。 色を付けることでソースにメリハリが生まれ、可読性が上がる。また、ス
Hatena::Diary::take-m - livedoor テクノロジーセミナー
昨日、livedoor テクノロジーセミナーに参加してきたので、そのメモと感想を。 アジェンダ セッション1: 「はてなの開発/運用体制について」 / はてな 伊藤直也氏 セッション2: 「livedoor Readerについて」 / ライブドア ma.la氏 セッション3: ディスカッション / はてな 伊藤直也氏、ライブドア 池邉氏 セッション4: 質疑応答 メモ 自分の意見は文字色を変えてます。 セッション1: 「はてなの開発/運用体制について」 / はてな 伊藤直也氏 id:naoya:20061214:1166063145 に発表資料。 はてブのサーバー構成について 特性に合わせて3つのセグメントに分けているのが、非常に特徴的だと思った。 通常リクエスト用 bot用 → リクエストが非常に多いがレスポンス速度はそんなに重要じゃない イメージやカウンタなど → Webサーバーに負荷
【特集】使ってる Issue Tracking - trac 楽々ことはじめ (1) パニックプロジェクトを生まないために (MYCOMジャーナル)
プロジェクトの情報共有を支えるための重要なタスクにドキュメンテーションと文書管理がある。あなたのプロジェクトでは適切な文書管理がなされているだろうか。通常、プロジェクトからは日々多くの種類/フォーマットの文書が生み出されている。そのため、文書管理に統制の無いプロジェクトでは、どこにある何を見ればいいのかを把握することでさえ、たちまち容易ではなくなってしまう。 プロジェクトに関する情報が増えてくる前に、一人でプロジェクト開発に従事しているあなたも、チームで開発をしているあなたも、散在する情報を整理したいと考えることだろう。 「今、プロジェクトで何が問題になっていて、何を片付けないといけないか」という情報群--ToDoやタスクリストとも表現できるこれらの情報群は、プロジェクト中のさまざまなシーンで出現し、これが管理されていないプロジェクトは、ほぼ確実に混乱に陥る。問題管理で取り扱う情報の種類は
わたしが知らないスゴ本は、きっとあなたが読んでいる: 名著！「デッドライン」
長くなりすぎたこのエントリのレジュメ …というか、見出しの一覧。これ見てご興味ある方はお読み下さいませ。 マネジメントの4つの本質 マネジメントおける簡潔で痛切なエッセンス（一部） 設計とデバッグに関する恐ろしい事実 残業と生産性とプレッシャーに関する恐ろしい事実 生産性の測定について 管理者の怒りについて 会議を効率よく行うための、たったひとつの冴えたやりかた 大事なことが、ずばり書いてある。背中を押したのは「ソフトウェア開発の名著を読む」なんだけど、確かに名著だ。初読は物語を楽しみ、再読、再々読で血肉にすべきだな。 延ばし延ばしにしてた一冊を読み始めて「どうして今まで読まなかったんだあぁぁっ」と叫びだすような逸品がある。本書がまさにそう。デマルコは「ピープルウェア」がピカイチと決め付けてた自分が恥ずかしい。 「ピープル」がプログラマ・チームリーダーの視点で書いているが、「デッドライン」
川o・-・）＜2nd life - Developer Enviroments Conference の発表資料
9/8 に開かれた DEcon で windows enviroments and vim という内容で発表してきました。主に自分が使ってる windows の開発に便利なツールと、vim についてプレゼンしてきました。時間大幅に押してしまいましてスイマセン…。 また、スピーカと参加者のみなさん、お疲れ様でした。他の方の開発環境やポリシーが聴けて大変参考になりました。あとカンジマン(id:tnx)には毎度の事ながら様々な準備お疲れ様でした。 自分のプレゼンには自作のはてな記法つかったプレゼンツールを使ったのですが、よくよく考えるとそれをエントリーに貼り付ければいいじゃん！ということに気づいたので、以下に発表資料を貼り付けておきます。 windows environments and vim secondlife 発表内容 windows での環境 どんなツールがあると便利か vim vim
ウノウラボ Unoh Labs: 共同開発を効率よく行う方法
尾藤正人です。 ウノウではおかげさまで順調にエンジニアの数が増えてきました。エンジニアが増えてくると、共同開発をいかに効率よく行うかが問題になってきます。n人の開発者がいれば開発スピードはn倍にはならず、n倍よりも落ちます。人数が多ければ多いほど、共同開発は難しくなり、ひどい場合には人数が増えたから開発スピードが落ちたということになりかねません。 ウノウでは共同開発を効率よく行うために様々な工夫を用いています。今回はウノウでどのようなステップで開発を行っているか紹介したいと思います。 subversion でソースコードを管理 ソースコード管理ソフトがなくては話になりません。ウノウではソースコードの管理に subversion を使ってます。subversion を使うことで過去の状態に簡単に戻すことができますし、個人の環境を完全に分離することができます。 subversion のコミット
WD Live! Web標準時代に求められるサイト構築法
Web標準時代に求められる サイト構築法 木達一仁 株式会社ミツエーリンクス WEB開発チーム フロントエンドエンジニア Web Standards Projectメンバー k-kidachi@mitsue.co.jp / kidachi@kazuhi.to 株式会社ミツエーリンクス WEB開発チーム フロントエンドエンジニア（2004年2月～） Web標準準拠サービスの立ち上げ/運用 Web標準Blogの運営 W3C Advisory Committee Representative 海外のWeb標準関連書籍和訳版の監修 Web Standards Project（WaSP）メンバー mixiにてWeb標準コミュニティを主催（2006年5月25日現在3260人が参加） 7月15日「Web標準の日」開催
BlogFish: Scaling Rails with Apache 2.2, mod_proxy_balancer and Mongrel
Unitl this week we used Lighttpd and FastCGI for MeinProf.de. The setup was nearly the same as described in the must read series scaling rails (1, 2, 3, 4) from poocs.net. We used this setup from day 1 but always had some small issues with Lighttpd. Lighttpd was crashing every couple of days. Nothing dramatic, we had a script that monitored Lighttpd and restarted it if necessary. During the last
画像配信の負荷分散も比較的簡単？（その1） - 最速配信研究会(@yamaz)
30万個ぐらいの静的ファイルを配信するサーバーの選び方 で静的な配信サーバに関することが述べられている. naoyaさんが公開されてるInside Hatena Bookmark's Backend の資料などを読むと、mod_perlなサーバーやMySQLサーバーの選び方の参考になったりするわけですが、世の中を見渡してみても、静的コンテンツ（画像とか）を配信するサーバーの指南書らしきものはなかなか見あたりませんでした。 なので、経験を元に書いてみることにします。 ということらしい.書いてあることはすべて同意だけど, つい3ヶ月くらい前まで 平均15k×1万URL×50億httpアクセス/day 平均4KByte×100万URL×3億HTTPアクセス/day な画像サーバと某所で向き合ってたため,ちょっとは役に立てるかもしれないと思ったので,私の経験を書いてみようと思う. 動画配信の負荷分
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
void GraphicWizardsLair( void ); // ニコニコ動画勉強会のPowerPointスライドがWebで公開されていた
naoyaのはてなダイアリー - ライブドアのテクノロジーセミナーでしゃべってきました。
