マトメー86400000 > selenium > index.htm Sort by: Update Auto() Image hover
37signals Jason Fried氏の講演 「より少ないシンプルな機能で競争する」：Goodpic
This shop will be powered by Are you the store owner? Log in here
[結]2005年9月 - Text::Hatena
山下達郎インタビュー / Text::Hatena / はてなダイアリーライターVersion 1.3.0を公開 / MacPaintのソースコードは今どこに? / 1bit-Paper / GTDツールリンク / フォーサイトクラブ・セミナー「ウェブ社会『大変化』への正しい対応・間違った対応」梅田望夫さん講演ログ / Google Print / タイムカプセル暗号 / IPAが暗号技術Toyocryptを世界で初めて解読、今後はAESやE0の安全性評価も / 「はてなグループ」の凄さを体感する / プレゼンハック ～プレゼン改善のための10個の小技～ / FTEXT数学 / ModelModelViewController / プログラム・プロムナード／Haskellプログラミング / RjpWiki: オープンソースの統計解析システムRのWiki / Subversion: リポジト
2005-09-12
いやはや、たまげた。民主党が守旧派みたいにうつちゃったんだろうなあ？ りんごとオレンジを比べるな。いやはや仰るとおりなんですが、別に比べたっていいではないか？深海の動きはゆっくり。レイヤーが違う。人の芝生を羨ましがっているわけではなくて、そう読めたとしたらわたしの言葉足らずなんだけど、自分は自分、人は人。楽しくやっています。 LLは高速道路があるけど、カーネルハックにはないとしたら、じゃあ、その道を作ってやろうと考えるのが多分わたしのスタイルである。一体全体どのくらい時間と手間と暇がかかるかはわからないけど。ゴールが見えているわけでも、これと言ったビジョンがあるわけでもなくロードマップもなんにもないけど取り合えず一歩踏み出す。 で、そんな事を考えている時、昔の事を思い出した。10年前、シリコンバレーに単身乗り込んで、とりあえづRDBMSの実装部隊にほうりこまれた時の事だ。ソースコードは絶望
NDOメソッド - naoyaのはてなダイアリー
プログラムを作ってみて途中でわからないことがあったらソースを公開して質問してみる 調べことをしてみてわからないことがあったので、調べごとした内容をサマリして掲載してわからないところを質問してみる 勉強してからじゃなくて勉強しながら学んだことを書いてみる というのをNDOメソッドと言います。というか言われました。要は give and take というやつです。時間をかけてプログラムを書いたり、調べごとをした、その結果を世の中に還元しているからこそ質問に回答をしてくれる白馬の王子様が現れるかもしれないというわけです。 必要に迫られてそれを解決し得るかもしれないモジュールを思いつきのままに書いてみたけれど、どうもうまくいかんなー、どうしよう……こりゃぁお蔵入りネタになりそうだ……でももったいないなぁ。じゃぁとりあえずわからないままにエントリとして投げたりしたら Perl ハカーな方がいい方法を
Perl の use と mod_perl、あと LLDN 感想ちょっと。 - naoyaのはてなダイアリー
それとperlのuseってどういうものなのか解らないんだけど、FastCGIのようなプロセス常駐させている場合、rubyのrequire*2したものがプロセスで共有されてて次回の起動コストはかからないんだけど、それとは違うのかな？ use するとこんないいことがあるんだよ、って書こうとしたら引用もとのコメントに miyagawa さんが書いてた。二つあるけど、どっちかというと大きいのは mod_perlのスタートアップ時にロードしてforkしたchild間で共有してメモリ消費を減らせる(シングルスレッドなFastCGIなら不要？) ここですね。 mod_perl だと、リクエスト毎に子プロセスを生成してリクエストに応じてプロセスを生成しそれに応答、あとはそのプロセスを使いまわすわけなんですが、use と require の違いが、子プロセスのメモリサイズに大きく影響してきます。 miyag
「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)：An Agile Way：オルタナティブ・ブログ
前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、 テスト容易性： EoT = Ease of Testing 変更容易性： EoC = Ease of Changing という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。 EoMの高い設計が、よいオブジェクト指向設計である。 ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフト
遅いコードを貯蓄する - Backnumbers: Steps to Phantasien
2005-08-21 遅いコードを貯蓄する 私は仕事柄, 書いたコードに実行速度を要求されることがある. 本当はいつも要求されていて, たまにそれに応えるという方が正しいかもしれない... とにかく, 権力者(上司, 顧客, 同僚)から "遅いので速くしろ" というお言葉を日常的に頂く. とはいえできる範囲の高速化は既に済んでいる. 無い袖は振れない. まわりからの圧力を前にすると, 高速化の余地あるコードがある種の資産に思えてくる. 高速化の "余地" にも色々ある. 直せは確実に速くなる性質の良いもの. 複雑さ故に速くなる "かもしれない" ように見える 不確実性の高い不良債権, まだプロファイルをとっていない未公開株のストックオプション, など. そこで, 優良な財をなす投資の方法 ... つまり遅くてかつ簡単に高速化できるコードを書く方法を, いくつか提案しておく. アクセサ変数を
最速インターフェース研究会 :: JavaScriptのデザインパターン - Singleton
JavaScriptじゃねえと書けねえよ、ってやり方でデザインパターンを実装してみるコーナー。とはいってもデザインパターンとか良くわからないので適当に覚えながら作る。 間違ってる箇所あったらつっこんでくれるとありがたいです。 わかりやすい文章を書く能力が欠如してるのでデザインパターンって何だとかそういうのはこっち参照。 http://d.hatena.ne.jp/naoya/20050813/1123924312 JavaScriptのコンストラクタはPerl同様自在に定義できます。returnでobjectを返してやれば、newの結果としてそいつを使います。 普通にシングルトンなクラスを実装するにはこんな感じだと思います。 function Singleton(){ var self = arguments.callee; if(self.instance == null){ this.
prototype.js でデザインパターン - Iterator
Ruby on Rails や Catalyst のプラグインなんかでは prototype.js という JavaScript のライブラリを使って、Ajax サポートを実現しています。prototype.js とフレームワークが必要な Ajax の JavaScript コードを吐き出してくれるので、Ruby プログラマや Perl プログラマは JavaScript の実装を意識しなくても Ajax なインタフェースが作れる、という風になっています。 こんな感じで prototype.js は Ajax な部分に注目が集まっていますが、ほかにも "Class-style OO" なフレームワークも内包してます。 JavaScript はプロトタイプベースのオブジェクト指向言語で、C++ や Java のようなクラスベースのオブジェクト指向言語とはちょっと実装が異なります。プロトタイプ
変わりつつあるソフトウェア開発の価値観
巻頭言 商用コンピュータが世に出てきてから、早50年以上が経過しています。 当初は、科学技術計算分野での電子「計算」機として生まれたコンピュータも、今では事務処理、意思決定支援、通信関連、娯楽等、さまざまな分野で利用されるようになり、真の情報処理機械と言えるまでに成長してきました。 また、ハードウェア性能は爆発的に、ソフトウェア開発手法もそれなりに進歩を続けています。 しかし、こういった進歩により劇的な周辺環境の変化が引き起こされ、ある時代にソフトウェア開発の真実であったことが、現在では間違いとなるような逆転現象も起こってきているのです。 例を挙げると、メモリが高価な頃は、1バイトでもメモリを節約するようなコーディングが優れているとされ、分かりやすさは二の次にされていました。 しかし、今や組み込み系以外では、こういったコーディングは「可読性を下げる悪習」と考えられていま
＊「ふっかつのじゅもんがちがいます。」 - ペアプロと上司でないマネージャはすっぱいブドウ
開発者が楽しく仕事できる環境とはを読んで。 ペアプロについて 以前いた会社を辞める前に、引継ぎとして（そして個人的な実験を兼ねて）ペアプロをしてみたことがある。確かに効率的だった。近藤さんのおっしゃるような効能を容易く体感できる。僕は何一つドキュメントを書かなかったが、しかしこの引継ぎは「xxx引継ぎ資料20050806.doc」なんていうWordファイルを書いてこれを元に1時間プレゼンして、このファイルをファイルサーバの奥深くに格納するよりもはるかに効果的だった。 ヒント：そういう引継ぎはやらないよりは幾分ましだが、せいぜい「話題の映画のあらすじを教えてもらったから世間話ができる」という程度のご利益しかない。大事なことはいつだって行間に書いてあるのだ。 ペアで作業を行うため仕事以外の事は一切できない（一人で作業しているとついついメールをチェックしたりウェブを見たりしてしまいます） 「これ
開発者が楽しく仕事できる環境とは:近藤淳也の新ネットコミュニティ論 - CNET Japan
立って会議をするだけでなく、はてな社内では他にも色々なことを試みています。その中でも、開発者が楽しく仕事ができるように、という観点でいくつか紹介してみたいと思います。 まずはペアプログラミング。これは、2人1組になってプログラムの開発を行うスタイルで、XP（エクストリームプログラミング）のプラクティスの一つとしても提唱されているものです。 2人でプログラムを開発するというのは、1人がプログラムを書き、もう一人が横からそれを見ている、という方法です。この方法を聞くと、1人がそれぞれの作業を行うよりも作業量が2分の1になってしまいそうな気がするものですが、実際はそれぞれが別々の作業をするよりも効率が上がる、という興味深い逆説的な現象が発生します。 ペアプログラミングの様子。こういうときはなぜかコーラが似合います。 なぜ2人1組でプログラミングをする方が1人ずつでやるよりも効率が上がるのでしょう
＠IT：初めてのプロジェクトリーダー
ソフトウェア開発チームを構成するメンバーは大きく2つの種類に分かれます。開発者とリーダーです。開発者にさまざまなスキルが必要なように、リーダーにもさまざまなスキルが必要です。多様なスキルの中で最も習得が難しいとされているのは、開発者と違う視点を持つことです。もし、（教科書どおりにやっているはずなのに）いまあなたがリーダーとしていま一つだと感じているのであれば、開発メンバーから、リーダーへの視点の切り替えが上手に行われていない可能性があります。 この連載を通じて私がお手伝いしたいのは、視点の切り替えです。切り替えというよりは、「もう1つの視点を持つ」といった方が適切かもしれません。メンバーとして、開発者としてプロジェクトチームに貢献してきたあなたが、リーダーとしてチームに貢献するために追加すべき視点を持つにはどうすればよいか？ 次の3つの切り口で説明していきたいと思います。 3つの切り口：「
わたしが知らないスゴ本は、きっとあなたが読んでいる: Wikiでプロジェクトマネジメントする4つの方法
「ブログでプロジェクトマネジメントする10の方法」への反応を見ていると、独り考え込むのでなくUPしてみるものだな、と思った。実務に適用している例や、Wikiでの試みがあることを知った。言及していただいた皆様、ありがとうございます。賛否ともども大変参考になり、中の人は感謝多謝することしきり。 Wikiを発展させた開発支援コラボレーションツールMrkrgnao（via:marsのメモ） Wikiを使った「Web向けLotus Notes」Jotspot（via:関心空間ラボ） 社内限定の非公開型ブログイントラブログ さらに、「Wiki との優位性が見えない」「ストレージサービスでええやん」というコメントがあったが、そのとおりだと思う。実際、前のプロジェクトでは Wiki+CVSで「設計書+コード管理」してたし。時系列に情報を積み重ねるのがブログなら、Wikiは樹構造的な展開に向いている。各人の
わたしが知らないスゴ本は、きっとあなたが読んでいる: ブログでプロジェクトマネジメントする10の方法
マーケティングツールとしてのブログが流行らしいが、開発現場のマネジメントとしてブログを使えないかという提案。イントラネットに閉じたローカルブログ導入のヒントとして自分メモでもある。 1.ステークホルダーのコミュニケーションツールとして 進捗報告やマイルストーン毎のレポートなど、プロジェクトでやりとりする情報はかなりのものだが、それらを全て一斉同報メールで送るのは大変かも～というのであれば、ブログが有効かと。 日報、週報、月報のような定期レポートだけでなく、随時更新されるリスクマネジメントリストや、毎時参照されるトラブルレポートも対象となる。更新するタイミングでステークホルダーにお知らせメールを送るのも簡単だし、RSSリーダで読むようにすれば、それすらも要らぬ。その際、以下のルール決めをして浸透させておく必要がある。 どのタイミングで 誰の責任において どのような情報が 公開されるのか（公開
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://amrita.s14.xrea.com/d/?date=20050921
専門家は個人の責任で情報発信するな - void GraphicWizardsLair( void ); //
QRコード作成ツールにDoS状態を引き起こす脆弱性
圏外からのひとこと(2005-06-23)今ここにある10年分の時間