takuto_hの日記
■編集元:ニュー速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
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,
イベント駆動型のプログラムでは、エラー処理の記述が面倒になることがある。これを何とかしたい。 例えば、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 ここまでが前提条件。 このプログラムのエラー処理を愚直に書くと、↓このよう
@knockout_kz 前もつぶやいたかもしれないが、子どもを複数人持つことのメリットは、「あらゆる子育てに対するこだわりが徹底できなくなること」と「子へのまなざしが分散されること」だと思っている。親の考えるこだわりを刷り込み、朝から晩まで監視して、では親も子も窮屈だろうから。 2011-01-04 20:45:50 @knockout_kz 長男と次男を見ていてもよくわかる。長男は申し訳ないがかなり親のこだわりをおしつけて育てた。だからまなざしが分散された今でも親の顔色を伺うようなそぶりをみせることがある。そして次男にはそれがない。たまたま年齢的なものもある(社会化されている)とは思うが、それだけではないと思っている 2011-01-04 21:01:39 @knockout_kz 親のこだわりを規範として育ったとして、子がパフォーマンスを発揮する時代にその規範がフィットするかどうか微
最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由 (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) 分離レベルがデフォルト(read comitted)のままだと,恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか? 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する? - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
僕が今やってる例のプロジェクト*1で、 この前、設計書を作ってお客さんに確認してもらった。 分厚い設計書で、何回も社内レビューをしてもらって、 メッセージIDのマッピングなど細かい点をイライラしながら直して 何度も印刷して、「最終版」、「最終版2」、「本当の最終版」という お馴染みのサブディレクトリができて、 やっとの思いでお客さんに提出したんだけど、どうやらぜんぜん見てくれてないみたいだ。 しかし、一緒に提出したユーザーマニュアルには、隅々まで目を通してくれていた。 お陰で、重要な仕様の誤解を発見することが出来た。 ユーザーマニュアルはそのままHTML化されて、 システムのHELPボタンから呼び出されるから、 お客さんとしても念入りにチェックしてくれたんだ。 ところで、設計書には大きく3つの役割がある。 ・お客さんが仕様を確認するため ・エンジニアが実装するため ・保守のため 僕は今回、
データベースには,「トランザクション分離レベル」というものがある。 以下では,それが なぜ必要なのか? デフォルトのレベルでは,どうして駄目なのか? PostgreSQLでは,どうやってレベルを変更・確認するのか? などを取り上げる。 トランザクション分離レベル トランザクション分離レベルとは: 複数のトランザクションが同時に実行された場合に、他のトランザクションからの影響がどのくらい「分離」するか,のレベル。 ANSI規格では,4つのレベルがある。 READ UNCOMMITTED (一番低い) READ COMMITTED REPEATABLE READ SERIALIZABLE(一番高い) 徹底比較!! PostgreSQL vs MySQL 第3回:トランザクションの比較 http://thinkit.co.jp/free/article/060... トランザクション処理に詳しく
どこかに就職したり、何か会社を興してみたりといった体験を持たない、生まれついての「プロの政治家」という人たち、 学校を出て、最初から政治家として活動して、努力した人たちが、そのまま最上階まで行ってしまうのは、恐ろしいことだと思う。 努力した人はしがみつく 何かの目的を持った人、目標を「これ」と決めて、それを実現するためのやりかたを考えた経験を持つ人は、 あらゆる場所が通過点になる。目標を達成したなら、たぶんまた別の目標が見つかって、やるべきことや、必要な資格なんかは、その都度変わってくるだろうから。 漠然と「努力」を重ねて、努力の「ご褒美」として、一番高い椅子を手に入れてしまった人には、もはや「上がりの先」を想像することができない。努力をもっとやろうにも、 そこにはもう、問題集とか、次のご褒美を用意してくれる誰かはいないから、先が見えない。 こういう人が頂点に座ってしまうと、今度はじゃあ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く