タグ

2010年12月20日のブックマーク (12件)

  • Godfather's Burger - masayang's diary

    昨夜は仕事場の仲間たちとBelmontのGodfather's Burgerで飲みい。初めて行ったが、実にいい店であった。なんでもデカいので胃袋の小さな人にはお勧めできない。夕方は混雑するので予約していくことを強く推奨。 メニュー →ビールが色々。パイント売り。強い人なら全種類いけるのでは。 前菜 →基は揚げ物。玉ねぎの揚げ物と、イカの揚げ物を頼んだ。皿が巨大。 ハンバーガー →でかい。 →積み重ねると、Nexus Oneよりも背が高い... →激辛ハラペーニョで死んだ人一名。 →ジャガイモは残ってしまった...

    Godfather's Burger - masayang's diary
    katzchang
    katzchang 2010/12/20
    はらへった。
  • 全てのプログラマーに読んでほしい 「プログラマが知るべき97のこと」 - yuumi3のお仕事日記

    やっとプログラムが書けるようになってきた人から、3年、10年とプログラミングしているベテランプログラマーまで、全てのプログラマーに一度読んでほしいです。 プログラマが知るべき97のこと 作者: 和田卓人,Kevlin Henney,夏目大出版社/メーカー: オライリージャパン発売日: 2010/12/18メディア: 単行(ソフトカバー)購入: 58人 クリック: 2,107回この商品を含むブログ (339件) を見る このには、たくさんの良き先輩のアドバイスが詰まっています。これだけのアドバイスが出来る先輩・同僚に恵まれた職場は少ないと思います、これだけの素晴らしいアドバイスが ¥1,900であなたのものに出来るのです! (どうしても\1,900出したくない人は、せめて オライリーのページの目次の読んで下さい。あなたがプログラマーなら読む時間以上の価値をもたらすはずです) このの読

    全てのプログラマーに読んでほしい 「プログラマが知るべき97のこと」 - yuumi3のお仕事日記
    katzchang
    katzchang 2010/12/20
    「プロのプログラマは、自分の書いたコードは隅々まで説明できなくてはいけない」大事。
  • SYNODOS JOURNAL : これからの「労働」の話をしよう 濱口桂一郎

    2010/12/207:0 これからの「労働」の話をしよう 濱口桂一郎 ◇「ブラック」だけど「ブラック」じゃなかった◇ 日の企業ではもともと、目先で労働法が踏みにじられているからといって、ミクロな正義を労働者が追求することは、愚かなことだと思われていました。とはいえ、それは「ブラック」だったのかと言えば、そうではありません。これが、今日の柱のひとつになります。 ところが、それは先々保障があるということが前提となっているわけで、これがなければただの「ブラック」なんですね。「働き方だけを見たら「ブラック」だけど、長期的に見たら実は「ブラック」じゃない」はずが、「ただのブラック」である企業が拡大してきた。それが、ここ十数年来の「ブラック企業」現象なるものを、マクロ的に説明できるロジックなんじゃないかなと思います。 この取引はいわば山口一男さんの言う「見返り型滅私奉公」に近かったわけです。滅私奉

    katzchang
    katzchang 2010/12/20
  • 検察庁で聞いてきました | Librahack : 容疑者から見た岡崎図書館事件

    「なぜ起訴猶予になったのか?」を聞きに検察庁へ行ってきました 朝日新聞 神田さんや岡崎市立中央図書館事件等 議論と検証のまとめの杉谷さんの取材では「私が罪を認めたので起訴猶予になった」とのことです。 朝日新聞 神田記者による検察への取材より 不起訴とした理由は「強い意図は証拠上認定できなかった。どれくらい業務に支障があったかという点でも、検索システムの障害になったのは比較的短時間だった。業務妨害罪としてそれほど悪質なものではない。人も反省している。」 ”嫌疑不十分”でなく”起訴猶予”とした理由は「人が罪を認めているから。」 杉谷氏の愛知県警への取材より 「攻撃ではない、と認識していながら、嫌疑なしではなく起訴猶予処分となった理由はなんですか」 との問いに対して、愛知県警は「故意が認められたということで、警察としてはそう判断している」 Librahackメモの通り、自分では罪を認めたつも

    katzchang
    katzchang 2010/12/20
    弁護士に相談すべき、ということだわね。
  • 「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催

    統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」(Empirical Software Engineering、実証的ソフトウェア工学)です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は? マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した

    「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催
    katzchang
    katzchang 2010/12/20
    「コンウェイの法則」は知らなかった。
  • 都議会、ソフトウェアのソースコードを規制する条例を可決 - カタチづくり

    2010年12月某日、都議会ではソフトウェアのソースコードを規制する条例案を可決した。 条例の内容は、可読性やメンテナンス性の悪いコードを不当に賛美あるいは誇張する書物を規制するもので、ソフトウェア工学を学んでいる学生の目に触れないようにすることを目的としたものである。条例が運用段階に入ると、都内の大学生協の書籍売場からはそういった書籍が姿を消す可能性が高い。また都議会では、今後都に対して納入されるシステムについてもソースコードを厳しく監視し、可読性やメンテナンス性に著しく劣ると判断されたコードは検収を上げないとも述べている。 これに対し、都内のギークたちが一斉に反発。「可読性」「メンテナンス性」「不当に賛美」といった指標は判断基準が明確でなく、解釈次第で規制の対象がどこまでも広げられるというのがその理由だ。 一方で、条例には賛同する声もある。都内のとあるSEは「ひどい連中は誰にも引き継げ

    都議会、ソフトウェアのソースコードを規制する条例を可決 - カタチづくり
    katzchang
    katzchang 2010/12/20
    「システム開発も建築業界のように免許制にすべき」と主張する人は、たまにいたりするよね。
  • 日本式(?)掛け算を観た外国人たちのコメント: 誤訳御免。

    (12/15)日式(?)掛け算を観た外国人たちのコメント (12/14)映画「フランダースの犬」ラストシーンの海外反応 (12/13)海外オタク達によるアニメの将来の見通し「ポジティブ or ネガティブ?」 (12/11)中国にオレンジ色の実物大ガンダム出現!!の海外反応 (12/10)日2022年W杯誘致プレゼンビデオを観た外国人たちの反応 (12/08)日はブラジル人をこんな風に見ている【海外掲示板】 (12/07)海外記事「100$するドリームクラブのフィギュアが悪夢」とその反響 (12/05)パンティ&ストッキング第10話「D City Rock」PVの海外反応 (12/04)「残酷な天使のテーゼ」の歌詞を書くだけの動画にいつく外国人たち (12/03)「日のRPGは古臭いのか?」を外国人が語るスレッド 管理人がお気に入りだったりする記事 ソニー「カ

    katzchang
    katzchang 2010/12/20
    マヤ式らしい。
  • MOONGIFT : アジャイル開発の管理に「ScrumMaster」 オープンソース・ソフトウェア/フリーウェアを毎日紹介

    ScrumMasterはPHP製のオープンソース・ソフトウェア。ウォーターフォール型のシステム開発はWeb系の開発においては何かとリスクが高い。プロジェクトが何度も火を噴き、その度にアジャイル開発などを検討する企業も多いのではないだろうか。 メイン画面 だがアジャイル開発はスタイルが大きく異なるので覚えるべきことがたくさんあるように感じてしまう。しかしそんなことはない。そのためのシステムを導入すればノウハウ含めてスタートしやすくなる。試してみたいのがScrumMasterだ。 ScrumMasterはスクラム型開発を取り扱うプロジェクト管理システムだ。1〜2週間程度のイテレーションを設定し、その中にタスクを入れていく。そしてその結果をバックログとして次回のイテレーションに活かしていく。その繰り返しを管理するためのシステムだ。 スプリントバックログ グループによる権限管理や、プロジェクトメン

    katzchang
    katzchang 2010/12/20
    これどうですか?
  • fluent interface呼び出し書式を正しくeclipse3.6でフォーマットする方法 - 達人プログラマーを目指して

    Java言語のコードの書式のひとつとして、fluent interface(流れるような*1インターフェース)という書き方が知られています。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?FluentInterface 構文的にはSmalltalkのようにメソッドの戻り値にメッセージ送信対象のオブジェクトを返却することで、一文で複数のメソッド呼び出しを行うという書き方です。以前、多くの日人がオブジェクト指向プログラミングを苦手とするのは英語アレルギーだからか? - 達人プログラマーを目指してで書いたように、英語脳になってないと必ずしもうれしくないこともありますが、英語の得意な外国人にとっては自然言語のように分かりやすく簡潔に記述できることもあり、最近のAPIでは結構流行しているようです。厳密にはFluentではないかもしれませんが、形式上チェーンで呼

    fluent interface呼び出し書式を正しくeclipse3.6でフォーマットする方法 - 達人プログラマーを目指して
    katzchang
    katzchang 2010/12/20
    これはほしかった。
  • ハタさんのブログ(復刻版) : Scala の trait って便利だよね。って話

    Scala Advent Calendar jp 2010の 12/20 を担当しました。Day 14です。 よろしくお願いします。 色々何か書こうか迷ったけど、traitについて書こうと思います。 scalaのtraitって、インタフェースのようでありながら実装を持てるので、色々便利ですよね。 javaからscalaと移行してきた人にとってtraitとはなんぞや?と思ってしまうので、そのあたりを書いてみようかと思います。 Slateによるtrait まず、traitだけを見ると、scalaのtraitは他の言語のソレと違っています。 例えが悪い(?)ですが、traitを持つSlateという言語(SELF系の言語で、small talkによく似ている言語です) の場合、traitはどちらかというと、メソッドの集合であって、そのtraitを使うことで多重継承等を行うようにできるヤツです

    katzchang
    katzchang 2010/12/20
  • しゃべるのがあんまり得意でない人って思考回路が最適化されている - ひらめき箱

    しゃべるのが苦手な人って、別のとこで凄い能力を持ってる人が多いなぁって思っていて、そのことについてつぶやいたものをちょっとまとめてみました。 しゃべるのがあんま得意ではない人って、独自の思考回路を進化させまくっている人が多い。自分の思考に最適化された構造をしているから、物を憶えるのが凄い得意だったり、一人の作業が凄く早かったり質が高かったりする。つまり「自分語」で脳が動いてるので、それを公用語に翻訳するのに時間がかかる http://twitter.com/#!/fta7/status/15939525465341952 独自の思考回路を進化させてきた人にとって重要なのは「コミュニケーション能力」というよりも、その回路の独自性を更に磨き上げていきながら、そこから生産されるものをどう「言葉」に変換するか、あるいは言葉以外の何かに変換するか、ってところなんだとおもう。つまりプロトコルをどうする

    しゃべるのがあんまり得意でない人って思考回路が最適化されている - ひらめき箱
    katzchang
    katzchang 2010/12/20
    シュレディンガーの非モテ論
  • TDDでLiftのバリデータを実装していく - @katzchang.contexts

    この記事はScala Advent Calendar jp 2010の13日目です。12/19予定だったけど、日付超えてしもたわ…。 この記事の全てのコードは https://github.com/katzchang/TDD-with-Lift にあります。 はじめに LiftはScalaで最も有名なフレームワークだろう。Scalaの能力が駆使され、ともすると取っ付きにくいとの噂もあるが、この際それはどうでもいい。フレームワークが用意するライブラリの随所に改造ポイントが見られ、もちろん、modelに対するバリデーションも独自に実装できる。…が、意外にもビルトインのバリデータは少ない。文字列の長さを検査する「ValidateLength」トレイトくらいしかないはず。 というわけで、今回はliftのmodelに対する「not null」バリデータを実装することにした。 使い心地として、Vali

    TDDでLiftのバリデータを実装していく - @katzchang.contexts
    katzchang
    katzchang 2010/12/20
    Lift2.1と2.2がまた微妙に違ってて戸惑ったりした。