ReadLine で CPAN を便利に - はちゅにっき
otsune さんに ☆ をつけられるたびに泣きそうな magicalhat です。 小さなことですが、大きな励みだったりします。 ありがとうございます＞＜ って、なんか気づいたら1月なんですけど。 今年も底辺からがんばっていきたいと思います。よろしくおねがいします。 さてさて今回は 「CPAN Shell でも TAB 補完したいよ！どうすればいいの？」 というお話。 もしかしたら、TAB 補完が使えるのが当たり前かもしれないけれど、Debian を再インストールした頃から、CPAN Shell で TAB 補完をしようとすると cpan[1]> o co[TAB] cpan[1]> o co^[ # <= conf と補完されてほしいのに。。。 という風に、変な文字が表示されるようになってしまいました。 しかも、履歴を出すために ↑ キーとか ↓キーとかを押した場合にも、呪文のような文
オススメCPANモジュールその1。 AnyEvent - TokuLog 改めB日記
というわけで、俺の独断と偏見によるオススメモジュールのコーナーです。 AnyEvent は poll/select/kqueue/epoll(4) などのイベントループを抽象化するライブラリです。似たような目的のものとして Danga::Socket, POE などがありますが、ライブラリ全体のインターフェースの完成度や速度などの点から AnyEvent を僕は一番押しています。 Pure Perl で利用できますし、インターフェースも安定しています。まだバリバリ開発されてますが、backward incompat な変更はされないようです。 作者が mlehmann 氏ということで、ドキュメントは丁寧ですが攻撃的な文章が目立ちますし、バグレポートすると異常な長文がかえってきたりするのでうっとーしかったりしますが、コードの品質はたかいので、気にする必要はないかとおもいます。コードの品質の前
スポーツ見るもの語る者〜フモフモコラム:すべての努力をし、すべてを出し切った、上村愛子さんの誇り高き世界4位。
7位、6位、5位、そして、4位。 バンクーバー五輪で、日本中から大きな注目と期待を集めた女子モーグル・上村愛子さんが決勝にのぞみ、4位となりました。初出場の長野五輪が7位。そこから五輪のたびにひとつずつ順位をあげ、今回はついに4位。またもメダルには手が届きませんでしたが、見事に世界の4位になりました。 今回の結果に関しては非常に妥当なもの。愛子さんの今季のW杯ランクは6位で、上位に入った3選手はそれぞれ3位、1位、4位。実力どおりの結果で、採点等にも疑義はありません。むしろ、上位勢に転倒が続出したことで愛子さんは実力順よりも上に位置していると見るべきところ。おそらくもう一度競技をやり直してもメダルには届かないでしょう。彼女が今持っているものを、すべて出しつくしたとしてもです。「惜しかったね」と声を掛けるのははばかられるような、力の差がそこにはありました。 上村愛子さんはアスリートとして特筆
若者、アウト！ - Chikirinの日記
録画してあったガイアの夜明け（2月9日分）を見た。おもしろかった。テレビ東京、グッドジョブ。 ちきりんは「世界の高齢化の最先端を走る日本の未来」に興味津々だ。世界のどこにもないユニークな社会になると確信しているし、今は想像もできないことが起りそうでとても楽しみ。 過去いろんなエントリで、ちょっとずつ未来社会の側面を描こうとしてきたけれど、“総合的にどんな感じになるの？”ってのは、ちきりんもなかなか表現できていない。多面的、具体的、かつビビッドに、未来の姿を描写するのは簡単じゃないのだ。それがこの番組を見ていたら、「おお〜、これじゃん！？」って感じだった。未来のこの国の姿がはっきり見える番組だった。 内容は、高齢者が派遣や内職という形で労働市場に流入しているという話で、でてきた事例は、 ＜ケース１＞ 「高齢社」という71歳の社長が率いる高齢者専門の派遣会社。登録する労働者は大手企業の管理職な
今の非モテは、フィクションを盛り上げる「告白至上主義」が生んだ被害者
いいことを教えてあげようか。 告白したからダメなんだよ。 ２７歳童貞。 彼女ができないって悩んでいた。恋をして告白して振られを繰り返す。 やっと諦めがついた。俺は容姿や性格という点で根本的にダメなんだと。誰からも受け入れられないんだと。 http://anond.hatelabo.jp/20100212005436 恋愛は、告白したら９割がた失敗する。 例えば、お前が告白するとき、絶対にＯＫしてもらえるはず！ って思ってたか？ ダメもとで告ってみて、断られたらすっぱり諦めよう！ なんて思って無かったか？ それ、完全に負けるパターンだろ。 恋愛上手な人は、絶対に告白なんてしない。 だって、いい雰囲気になる前に告白なんかしたら、友達以上恋人未満っていう、 女の子が大好きな、恋愛で一番楽しい期間を全部ぶっ壊しちゃうじゃん。 だから、経験値がたまった大人の恋愛では、完全に仲良くなる前に告白なんか絶
ソースコードのコメントについて - 酒井和真のブログ
パッケージソフトの開発に携わっていると、長期的にメンテナンス・機能追加を繰り返すためソースコードの保守性をいやがおうにも意識することになります。 ソースコードの保守性の観点から私が嫌いなのが、「不要なコメント」です。 その際たるものが、修正箇所の最初と最後に「日付 名前 開始（終了）」を記入しているだけのコメントです。まっとうな開発であれば何らかのソースコードバージョン管理ツール（subversionやCVS）を使っているでしょうから、全くの無意味です（継続的な修正や機能追加でこういったコメントが累積していってはたまりません）。 これは極端な例としても、私は極力コメントをソースコードに入れないほうがいいと思っています。私なりのソースコードコメントについてのスタンスは以下の通りです。 クラス・メソッドに対しては、コメントをきちんと書く。クラスやメソッドに対しては、多くの言語では標準のコメント
小野和俊のブログ:ソースコードのコメント率は20%を切ることが望ましい
大学の研究室の教官は昔NTT研究所の所長をされていた苗村先生という人で(と言いつつ私は大学の研究室にほとんど顔を出していなかったのだけれど)、彼の発言のうち印象に残っているものの一つとして、昔はソースコードのコメント率が50%を切るものはドキュメント不足で品質が低いものとされた、という内容のものがあった。 今、改めて考えて、どのような言語であってもどのようなコーディング規約であっても、私はソースコードのコメント率は原則20%を切ることが望ましいと思う。可読性の意味でもメンテナビリティの意味でも、開発生産性の意味でも。私が考えるに、本来コンピュータが読むためのものであるソースコードに人が読むためのコメントを付け加えなければならないのは、次の２通りの場合だけである。 1.公開されるAPI APIやソースコードそのものが公開される場合、利用者は不特定多数となり、利用者のスキルにもばらつきが出て、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
