タグ

2009年11月10日のブックマーク (13件)

  • Agileでやってるけどデスマったw

    Agileでデスマになったのでそのログです。 この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。 契約と総生産量の関係性 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ!とか残業して頑張れ!とかいうのはAgileを知らない証拠。 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーが

    Agileでやってるけどデスマったw
  • Unicorn!

    AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be

    Unicorn!
  • Route 477(2009-11-10)

    ■ [ruby] 大規模Railsサイトのための新しいHTTPサーバ、Unicorn githubの中の人が、ブログで「Unicorn使い始めて一ヶ月くらい経つけどいい感じだよ」と書いています。 適当に要点だけ拾ってみました。 Unicornって何よ? UnicornはRubyのためのHTTPサーバ。MongrelやThinのようなものだけど、全く違う設計と思想を持っている ありがちな構成 [mongrel] [mongrel] .. [nginx] -> [haproxy] -> [mongrel] [mongrel] .. [mongrel] [mongrel] .. 問題点: あるactionの処理に60秒以上かかったとき、Mongrelが当該スレッドをkillしようとして固まることがある メモリが一定量を超えたときMongrelを再起動するのが遅い。 デプロイ時に9個のmongre

    Route 477(2009-11-10)
  • NoSQL – SQLはもう古い?

    Photo by shindotv ここ最近、海外のブログで「NoSQL」という単語をちょこちょこと見るようになりました。 これは新しいデータベースのムーブメントで、「SQL=リレーショナル」ではないデータベースの事を指しています。 NoSQL DBサーバの有名な物は、Facebookがリリースした「Cassandra」、Erlangで書かれた「CouchDB」、日からは、mixiがリリースしている「TokyoTyrant」があります。 またGoogle App Engineでは、DataStoreというBigTableベースのNoSQLサービスが提供されています。 ある程度ユーザを集めたコンシューマ向けサービスは、大抵の場合パフォーマンスとの戦いとなります。 技術誌の中でも「スケールアウト技法」的な記事を目にすることが増えてきたことからも、多くのサイト運営者が、パフォーマンスの問題を抱

    NoSQL – SQLはもう古い?
  • 記者を強烈に萎えさせるダメリリースの破壊力 | 初代編集長ブログ―安田英久

    今日は、プレスリリース(ニュースリリース)の書き方について。編集部には日々いろいろなリリースが届くのですが、なかには、かなりの破壊力をもって「リリースをチェックする気力」を失わせる、強烈なダメリリースがあるのです。そのいくつかを紹介しましょう。 ※2009-11-16 当初「仏の顔」などの「聖☆おにいさん」関連のネタを埋め込んでいましたが、元ネタを知らない人にはわかりづらいうえにネタとしても意味が薄かったので書き換えました。 Web担編集部では、インターネットマガジン時代からのリリース宛先を含めて、日々届くリリースをチェックしているのですが、IT/ウェブ/マーケ系なので、届くリリースの数は1週間に1000~2000件ほど。そんななかから、救いようのないリリースを、メールソフトの「ダメリリース」フォルダに保存しておくのが密かな趣味だったりします。 リリースのチェックにはあまり時間をかけられな

    記者を強烈に萎えさせるダメリリースの破壊力 | 初代編集長ブログ―安田英久
  • 青方偏移 » この一年で得たもの

    いろいろと多忙で忘れかけていたのだけど、前々職を辞めてから一年が経過した。いや、それ以降が激動過ぎて振り返る余裕がなかったんだってばさ。ちょうど手がけていた仕事がちょっとだけ一段落したので、この隙に一年を振り返っておこうと思う。 そもそも、前々職を辞めると決めたのが2008年の初夏のあたり。11年ほど続けていた仕事も、そろそろ考え直す時期に来ていた。今後もこの会社で同じように仕事を続けるのか? 否、と答えを出した。何だかんだ言いつつも、この仕事は好きだし、職場もそんなに悪くないと思う。でも、このまま定年まで続けるかと問われれば、それはない、とも思った。歳の頃は34。違う世界に飛び込むなら、今が最後のチャンスだと思った。これを逃したら、後は会社に意地でもしがみつくような人生しかない。リスクはあるけど、このまま人生が固定されてしまう危険よりは遥かにマシ。辞めることを決断した。 次に行くべき職場

  • 相互情報量(mutual information)についてのメモ3 - uncertain world

    色々試してみてたら, 共起語の各共起回数が少ない場合に相互情報量を使うのは 一つの手段としてアリなのかもとか思った. 例1:相互情報量のが意味がありそうな結果 例2:どっちもまぁまぁ 例3:共起語のが良い結果

    相互情報量(mutual information)についてのメモ3 - uncertain world
  • WEBrickできみにも書けるWebサーバ - バリケンのRuby日記 - Rubyist

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    WEBrickできみにも書けるWebサーバ - バリケンのRuby日記 - Rubyist
  • Time Machineが遅い場合の対策 for Snow Leopard | Happy My Life

    TimeMachineでのバックアップは毎回外部ハードディスクで行っている。これが一番早く終るから。 で、たまにバックアップのペースが1時間あたり1GBなど、超スローになったりする。というか、さっき起きた。 今回の原因はアンチウイルスソフトだったが、他にも遅くする要因がいくつかあるらしい。 調べていくうちに対策方法が見つかったので、「これだけ対策しておけば、タイムマシーンが遅くなる原因は解決するでしょ」という事例を列挙しておく。 TimeMachine対策 アンチウイルスを無効にする 取扱説明書で無効にする方法を確認する。ダメならアンインストールするしか…。 VMWare Fusion, 英和辞書 等の大容量ファイルはTimeMachineバックアップ対象から除外 別パーティション等に手動でバックアップすると早い。どのみに丸ごとコピーしなきゃいけないのだから(TimeMachineは差分で

  • 相互情報量(mutual information)についてのメモ - uncertain world

    推薦の勉強の一環のメモです。 相互情報量とは、単語Aが出たら単語Bも文書Xに出るという 情報量の計算に使えそうな理論。 これをクラスタリングする際の指標に使えないかと模索中です。 数式は下記の通り。 数Aとか数Bが超苦手だったので、 解釈があっているのかアレなのですが、 この式をこんな風に解釈できるんじゃないかと考えてみました。 (正しい数式じゃないのでご注意ください) 相互情報量 = log( (全文書に出現した単語の総数 * 単語Aと単語Bの共起頻度) / (単語Aの出現頻度 * 単語Bの出現頻度) ) 多分色々間違ってるような気もするけど。 で、作ったのが以下のSQL。 insert into term_matual_infos( select t1.id, t2.id, log( -- T1 ( -- 語の総数 (select count(id) from terms) * --

    相互情報量(mutual information)についてのメモ - uncertain world
  • TeXworks

    lowering the entry barrier to the TeX world by Jonathan Kew, Stefan Löffler, Charlie Sharpsteen News (Feb 2024) TeXworks 0.6.9 released (Get it | Changes) (Feb 2023) TeXworks 0.6.8 released (Changes) (Feb 2022) TeXworks 0.6.7 released (Changes) (Mar 2021) TeXworks 0.6.6 released (Changes) (Mar 2020) TeXworks 0.6.5 released (Changes) (Mar 2020) TeXworks 0.6.4 released (Changes) (Mar 2019) TeXworks

  • 相互情報量(mutual information)についてのメモ2 - uncertain world

    テスト結果をつらつら書いてると長くなりそうなので記事を分けた. 情報量にidf値を用いてやってみた. 単語Aが出たら単語Bも出るっていう確率は分子で行っているので, 分母はidfってゆー,対極的重み付けのスコアを使ってみる. 相互情報量 = log( (全文書に出現した単語の総数 * 単語Aと単語Bの共起頻度) / (単語Aのidf値 * 単語Bのidf値) ) 発行したSQLは以下の通り. select t1.id, t1.name, t2.id, t2.name, log( -- T1 ( -- 語の総数 (select count(id) from terms as t_cnt) * -- AとBの共起回数 ( select count(term_id) as co_cnt from document_terms a join terms b on a.term_id = b.id

    相互情報量(mutual information)についてのメモ2 - uncertain world
  • Safari で常にタブで開く設定(新しいウィンドウを開かない) - @kyanny's blog

    id:faultier++ に教えてもらいました。隠し設定らしい。 $ defaults write com.apple.Safari TargetedClicksCreateTabs -bool trueこれで ok LDRize 超便利になった!

    Safari で常にタブで開く設定(新しいウィンドウを開かない) - @kyanny's blog
    conceal-rs
    conceal-rs 2009/11/10
    タブの設定