github に gem を公開する - 2nd life (移転しました)
http://github.com/ 最近一部で話題沸騰の github。github は Rails で作られたアプリケーションでは、自分が知りうる限り一番の完成度と使いやすさを誇るんじゃないか、と思っています。 ソースコードツリーの見やすさ、(g)zipでくれ機能、各種 git の情報へのアクセスしやすさ、最初に git レポジトリを作ったとき表示されるチュートリアルと云った基本的なことはもちろんですが、オープンソースプロジェクト・コミュニティを加速させるであろう、分散レポジトリを利用した様々な機能がすばらしいですね。 誰かが公開してるレポジトリを fork ボタン一つで自分のレポジトリにクローンし、いろいろ変更を加え、大本に取り込んで欲しいなぁ、と思ったら pull request。大本のコミッタは気に入れば pull で取り込めばよいし、もし気に入らなかったとしても、変更者がそのフ
「ふりかえり」が失敗する８つの理由：An Agile Way：オルタナティブ・ブログ
「アジャイルレトロスペクティブ」の著者、イースターダービーのStickymindsの短い記事です。 「ふりかえり」が失敗する８つの理由 Eight Reasons Retrospectives Fail ぼくは Retrospectives を「ふりかえり」、と訳している。オブジェクト倶楽部のプロジェクトファシリテーションのページに、天野さんが、日本語の「ふりかえりガイド」(PDF)もかいている。 簡単にまとめると、 「ふりかえり」が失敗する８つの理由 １．準備不足。 ⇒アジェンダをしっかり用意すること。 ２．焦点があいまい。 ⇒前回のイテレーションの改善に集中。 ３．データが集まっていない。 ⇒何かを変えようとするまえに、「実際に何が起きていたか」を話す。 ４．１人か２人が会議全体の会話を独占してしまう。 ⇒ペアにしたり、グループを作ったりして話あうアクティビティを持つ。 ５．自分たちで
hide-k.net#blog: テストのもう一つの使い道
品質保証だとか、リファクタリング時の精神安定剤だとか言われてるテストですが、実はもう一つ重要な使い道があります。 それは実践的なドキュメントとしてです。 まぁ、もともとTDD(テスト駆動開発)なんかだと仕様の代わりとして扱われるのだから、当たり前って言えば当たり前なんですけどね。 CPANモジュールには大体POD(Perl Old Document)が付いててSYNOPSIS(使い方)が最初のほうにドンと書いてあるのですが、大雑把過ぎたり機能のごく一部だけだったりでちょっと物足りないという貴兄や、英語で長々と説明されるよりも実際の使われ方見たほうが早いっていう貴兄にはテストを眺めるのがもってこいです。 Perlモジュールのテストを見るにはアーカイブを展開してt/以下をのぞいてみてください。まともなモジュールなら山ほどテストが見つかるはずです。運がよければ探してる機能が見つかるはず。 実際の
偉大になる方法:Geekなぺーじ
「成功の秘訣」という記事がありました。 CNN Moneyで掲載されていた「What is takes to be great(偉大になる方法)」という記事の要約でした。 「偉大」って何だろう等色々と疑問は尽きないとは思いますが、まあ、やっぱり「努力」という事でしょうか。 以下、紹介されていた項目です。 努力以外にない 練習が熟達への道 「才能」という考えに対する懐疑論 先人の事例を参考にすべし ビジネスに置き換えると、仕事をこなし続ける事 全く同じ事でも視点(マインドセット)を変えると得られるものが変化する 到達点を明確に で、結局何故成功するの？⇒わからん。でも「才能が無い」と言ってちょっとした事であきらめるのは良くない 元ネタの最大の論点は「才能」という幻影にとらわれ過ぎない方が良いということなのかも知れません。
Tracプラグインのインストール (Re::Monologue)
Tracはデフォルトではコマンドラインでの作業やtrac.iniの変更をしないと設定のカスタマイズができないのでプラグインを入れました。環境は引き続きFreeBSD 6.0-RELEASE。 まず任意のユーザに管理権限を与えておきます。 次にプラグインを利用する準備をしておきます。python_egg_cacheのディレクトリを作成してapahceで読める権限にしておき、 # mkdir /var/trac/python_egg_cache # chown www:www /var/trac/python_egg_cache/ apacheのconfに書き加えておきます。 # vi /usr/local/etc/apache22/Includes/virtual.conf <Location /trac> SetEnv PYTHON_EGG_CACHE /var/trac/python_e
MOONGIFT: » GoogleのソースレビューシステムMondrianのオープンソース版「Rietveld」:オープンソースを毎日紹介
※ 一部の画面はデモより Googleの高度なエンジニアリングを支える技術の一つにソースコードレビューがある。ソースの修正点について、レビューし、議論することでさらに良いコードができあがっていく。世界中にいるエンジニアのために、議論はネットを介して行うことになる。 ソースコードの行ごとにコメントが書ける そのためのシステムがMondrianだ。これを作ったのはGuido van Rossum氏、Python開発者でもある方だ。そしてこのMondrianをなんとかオープンソースとして公開したいと願ってきたRossum氏が実現させたのがこのソフトウェアだ。 今回紹介するオープンソース・ソフトウェアはRietveld、Google App Engineで作られたソースコードレビューシステムだ。 Rietveldは任意のリポジトリに対して、古い版と新しい版のソースの差分を表示し、レビューを行うこと
http://michilu.com/django/doc-ja/db-api/
データモデル を作成したら、次はデータベースからデータを取り出す必要があ ります。このドキュメントでは、モデルから利用できるデータベース抽象化 API と、 オブジェクトを生成、取得、更新する方法について説明します。 このリファレンスでは、以下のような Poll アプリケーションを参考に話を進めま す: class Blog(models.Model): name = models.CharField(max_length=100) tagline = models.TextField() def __unicode__(self): return self.name class Author(models.Model): name = models.CharField(max_length=50) email = models.EmailField() def __unicode__(s
GTD 再入門 (2) あなたの頭脳の中の高速道路
当たり前の話から始めましょう。 車がほとんどいない道路と、他の車で混雑している道路では、どっちの方が存分に加速ができるでしょうか？ もちろん前者ですね。 では、車はけっこういるのですが直線で見通しがついていて他の車の動きが予測できる高速道路と、道が曲がりくねっていて、他の車の動きも予測しづらい道路ではどうでしょう？ やはり、前者の方が走りやすそうです。 最初の例は、「やることが少ない」VS 「やることが多い」という例だと思ってください。単にやる事が少ない方が効率がいいという場合です。それに対して次の例は「GTD がうまく導入できている場合」VS 「GTD がない場合」と言えます。車の混雑の度合いも性能も変わらなくても、走りやすい道をつくれば加速できるという例です。 このように GTD はあなたの能力を高めてくれる魔法のような方法を提示する訳ではなく、単に走りやすい道路を造るものといってもい
TracPermissions – アクセンスのおまけ
Trac uses a simple, case sensitive, permission system to control what users can and can't access. Permission privileges are managed using the trac-admin tool or (new in version 0.11) the General / Permissions panel in the Admin tab of the web interface. In addition to the default permission policy described in this page, it is possible to activate additional permission policies by enabling plugins
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
