タグ

2011年1月6日のブックマーク (13件)

  • takuto_hの日記

    takuto_hの日記

    katzchang
    katzchang 2011/01/06
    「データと操作名で操作が決まる」は乱暴じゃない?OO以外でも成り立つように見える。でも、Javaの項は同意過ぎて困る。
  • DIY娘「車の傷消しで数万払うとかwww」

    ■編集元:ニュー速VIP+板より「DIY娘「車の傷消しで数万払うとかwww」」 1 名も無き被検体774号+ :2010/11/25(木) 23:11:54.56 ID:b9U3oaLX0 名も無き被検体774号+ :2010/11/25(木) 23:16:00.28 ID:b9U3oaLX0 男「リモコンのこのボタンだけ効かないな~」 男「買い換えないと」 DIY娘「もったいない!!」 DIY娘「そんな時は分解してドータイトを・・・」 3 名も無き被検体774号+ :2010/11/25(木) 23:21:55.28 ID:b9U3oaLX0 男「厨二の時に貼ったステッカーが汚いな」 男「剥がしても汚いし><」 DIY娘「そんな時はZIPPOオイルで・・・」 4 名も無き被検体774号+ :2010/11/25(木) 23:35:27.43 ID:b9U3oaLX0

    katzchang
    katzchang 2011/01/06
    「あんたみたいな人がいるから、ねじ山が潰れたり・・・等々」大変申し訳ございませんでした。
  • Types vs classes: what is the difference? | Lambda the Ultimate

    As far as I can tell, a class is exactly the combination of a type, a (possibly trivial) constructor and optionally a subtyping relation. Of course, in OOP languages, classes are types, while most types are not classes. In pure object languages, by opposition (e.g. Smalltalk, Scala, perhaps Python), every type maps to a class. So, why do people confuse types and classes ? Probably because in Java,

    katzchang
    katzchang 2011/01/06
    あとでがんばる。
  • 継承は害悪か。

    くっくっkura 🇯🇵🦀 @PG_kura OOP で継承は害悪だとは思うけども、実際に継承を言語から消去したとして一般 PG に受け入れられる言語になり得るだろーか。 2010-12-31 18:04:33

    継承は害悪か。
    katzchang
    katzchang 2011/01/06
  • イベント駆動型プログラムのエラー処理 - sdyuki-devel

    イベント駆動型のプログラムでは、エラー処理の記述が面倒になることがある。これを何とかしたい。 例えば、keyからidを引き、idからdata引くプログラムを書きたいとする。 手続き型で書くと以下のようになる: def doit(key) id = get_id(key) data = get_data(id) return data end ここで、get_id と get_data は長くブロックするので、イベント駆動型にしたいとする。 そうするとプログラムの正常系の処理は↓このようになる。 def doit(key, &callback) get_id(key) {|id| get_data(id) {|data| callback.call(data) } } # futureを返すのは良いアイディア end ここまでが前提条件。 このプログラムのエラー処理を愚直に書くと、↓このよう

    イベント駆動型プログラムのエラー処理 - sdyuki-devel
    katzchang
    katzchang 2011/01/06
    あとで。
  • http://hagi.is.s.u-tokyo.ac.jp/pub/essay/hagiya/cp/4

    katzchang
    katzchang 2011/01/06
  • 子どもが2人以上いるメリット

    @knockout_kz 前もつぶやいたかもしれないが、子どもを複数人持つことのメリットは、「あらゆる子育てに対するこだわりが徹底できなくなること」と「子へのまなざしが分散されること」だと思っている。親の考えるこだわりを刷り込み、朝から晩まで監視して、では親も子も窮屈だろうから。 2011-01-04 20:45:50 @knockout_kz 長男と次男を見ていてもよくわかる。長男は申し訳ないがかなり親のこだわりをおしつけて育てた。だからまなざしが分散された今でも親の顔色を伺うようなそぶりをみせることがある。そして次男にはそれがない。たまたま年齢的なものもある(社会化されている)とは思うが、それだけではないと思っている 2011-01-04 21:01:39 @knockout_kz 親のこだわりを規範として育ったとして、子がパフォーマンスを発揮する時代にその規範がフィットするかどうか微

    子どもが2人以上いるメリット
    katzchang
    katzchang 2011/01/06
  • 明日のためにその1:トランザクション処理に依存しすぎない - masayang's diary

    最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) 分離レベルがデフォルト(read comitted)のままだと,恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか? 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、

    明日のためにその1:トランザクション処理に依存しすぎない - masayang's diary
    katzchang
    katzchang 2011/01/06
    例示のケースでは、その時点での社員のリストをガツッと取ってきて、アプリケーション内で数え上げて分配する方で作り始るかなーと思った。
  • 僕がTDDをやめた理由 - カタチづくり

    タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する? - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し

    僕がTDDをやめた理由 - カタチづくり
    katzchang
    katzchang 2011/01/06
    結果の評価基準が感覚的で暗黙的なものは、テストコードに起こしにくいというお話。そういう部分をどう切り分けるかが勝負なんですかねぇ。
  • 設計書よりもユーザーマニュアルを書こう! - レベルエンター山本大のブログ

    僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージIDのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版2」、「当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく3つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、

    設計書よりもユーザーマニュアルを書こう! - レベルエンター山本大のブログ
    katzchang
    katzchang 2011/01/06
    ですよね。
  • かなり性格のいい猫でも子猫産んだらしばらく触らせてくれないもの。

    かなり性格のいいでも子産んだらしばらく触らせてくれないもの。

    かなり性格のいい猫でも子猫産んだらしばらく触らせてくれないもの。
    katzchang
    katzchang 2011/01/06
    育児疲れする猫を想像した!
  • DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して

    データベースには,「トランザクション分離レベル」というものがある。 以下では,それが なぜ必要なのか? デフォルトのレベルでは,どうして駄目なのか? PostgreSQLでは,どうやってレベルを変更・確認するのか? などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは: 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか,のレベル。 ANSI規格では,4つのレベルがある。 READ UNCOMMITTED (一番低い) READ COMMITTED REPEATABLE READ SERIALIZABLE(一番高い) 徹底比較!! PostgreSQL vs MySQL 第3回:トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく

    DBの「トランザクション分離レベル」が必要な理由  (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) - 主に言語とシステム開発に関して
    katzchang
    katzchang 2011/01/06
    「分離レベルが低い場合に発生する不具合のサンプル」はありがちだなぁ。
  • 努力には正しい方向がある - レジデント初期研修用資料

    どこかに就職したり、何か会社を興してみたりといった体験を持たない、生まれついての「プロの政治家」という人たち、 学校を出て、最初から政治家として活動して、努力した人たちが、そのまま最上階まで行ってしまうのは、恐ろしいことだと思う。 努力した人はしがみつく 何かの目的を持った人、目標を「これ」と決めて、それを実現するためのやりかたを考えた経験を持つ人は、 あらゆる場所が通過点になる。目標を達成したなら、たぶんまた別の目標が見つかって、やるべきことや、必要な資格なんかは、その都度変わってくるだろうから。 漠然と「努力」を重ねて、努力の「ご褒美」として、一番高い椅子を手に入れてしまった人には、もはや「上がりの先」を想像することができない。努力をもっとやろうにも、 そこにはもう、問題集とか、次のご褒美を用意してくれる誰かはいないから、先が見えない。 こういう人が頂点に座ってしまうと、今度はじゃあ、

    katzchang
    katzchang 2011/01/06