programmingとdesignに関するllillのブックマーク (16)

  • エラーメッセージは 2W1H がいいんじゃないか

    良くあるダメなエラーメッセージ エラーが起きたときは、以下のようにエラーメッセージをどこかしらに出力すると思います。 $c->log->error('something wrong!'); ただ、このエラーメッセージって、実際に発生したときには意味がわからないことが多いのです。 $c->log->error('error!'); 気でこういう「error!」とだけ吐くメッセージだと、エラーが起きたことしか伝わってきません。程度の差はあれ意味のわからないエラーメッセージはこの世にあふれているかと思います。 機械的なエラー情報 そういうわけで、たいていは Exception クラスや Logger クラスで多くの補助が受けられるようになっていると思います。 発生時刻 発生場所 stack trace 変数の状態 ただ、このような機械的な情報だけだと、結局、運用上は対応が難しい場面ってのが多か

    エラーメッセージは 2W1H がいいんじゃないか
    llill
    llill 2016/07/19
    メッセージはプログラマから見るといかにも枝葉の先の話だけど、運用者が直に触れるレイヤーなのでシステムの利便性を大きく左右する。拘りたいものです
  • 主キーはインデックスではない - 設計者の発言

    仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス(キー)というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルXがある。ところが、別のテーブルYからテーブルXの特定レコードにアクセ

    主キーはインデックスではない - 設計者の発言
    llill
    llill 2014/08/27
    直前のエントリと併せて読みたい。理想像は理解してても業務に精通していないと到達不能であるところから現実に浸食されていくんですよね
  • LevelDB入門 (基本編) - from scratch

    さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDBGoogle のBigTableをベースにしたアーキテクチャを持

    LevelDB入門 (基本編) - from scratch
  • 定期的に繰り返し実行する簡単ではないお仕事 - やねうらおブログ(移転しました)

    いやー、この問題は当に難しい。難しすぎて、どうやって解決すればいいかいまだによくわからない。わからないので、ここに書いてみる。 最初、とあるお客さんのために「ひよこの餌やりプログラム(仮)」を作っていたんだ。開始ボタンを押すとひよこの餌が出てくる。たったそれだけのプログラム。 今回は、これを「定期的に実行する機能が欲しい」と言われた。 この要望を実現するのがすこぶる難しかったんだ。 「やねうらおってそんなプログラムすら書けないの?老害なの?」 とか言わないで欲しい。この問題、当に難しいんだよ! ■ 1度目のひよこの全滅 まず、この要望に沿って、私の会社のプログラマが当初、次のようなダイアログをつけたわけだ。 繰り返し実行のところにチェックを入れた場合、ここで指定された時間後にも繰り返し実行する。単位は分で指定する。1日ならば60×24 = 1440を指定する。そうすると、ひよこの餌やり

    llill
    llill 2012/06/26
    ひよこをたすけてあげてー
  • データベースの間違った使い方10項目

    一般的なシステムで広く利用されているリレーショナルデータベースですが、システムの進化と共にデータベースの構造も複雑になりがちです。RestMQの作者、Gleicon Moraes氏の公開したスライドがシステムが複雑化していく様子をわかりやすく説明した上で「アンチパターン」を提示していました。 それによるとデータベースのアンチパターンは以下の通り。 動的なテーブルの作成 テーブルをキャッシュとして使う テーブルをキューとして使う テーブルをログとして使う 分散したグローバルなロック ストアドプロシージャ 使われない項目 JOIN地獄 ORMによって繰り返されるクエリ 負荷のコントロール どれも理由があって採用されるデザインですが、確かに後に問題を引き起こした経験もあり耳が痛い感じですね。スライド内ではそれぞれの問題についての解決策としてMongoDBやRestMQなどの利用を進めています。「

    データベースの間違った使い方10項目
  • 3回に1回出力するだけの簡単ではないお仕事 - やねうらおブログ(移転しました)

    なんかさ、3回に1回出力するだけの簡単なプログラムのお仕事ってあるじゃん。 if ( (++counter % 3) == 0) printf("Fizz\n"); これって意外と難しいんだよね。 ……なんてことを言うと「おいおい、天下のやねうらお、ついに頭おかしくなったか」とか言われるだろうけど、これ実際うちの仕事であった話で、このコードが原因でお客さんと大きなトラブルになった。 あまり具体的には言えないので、ちょっと別のものに置き換えて話すけど、それは、ひよこの餌やりプログラム(仮)だったわけ。 上のプログラムは、3回に1回だけど、このソフトには、N時間に1回、餌をやるロジックが書いてあった。 if ( (++counter % N) == 0) printf("餌やるでー\n"); なんかこんな感じな。それでNの値は、UI(ユーザーインターフェース)で調整できる作りにしてあった。一度

    3回に1回出力するだけの簡単ではないお仕事 - やねうらおブログ(移転しました)
    llill
    llill 2010/10/12
    求められていたのはn回に1回動くマシーンではなくひよこの餌やりマシーンだったのだ!でもお客さんはn回に1回動くマシーン作ってくれ!って言ってくるんだよね…
  • ECMAScript 規定: ドル記号は機械的に生成されるコード中のみの使用を意図される

    えんじに🐈にゃーん💉💉 @uupaa うん。$ ってネームスペースとしては全く効率的じゃない。というか疲れる。 PHP やると疲労感を感じるのは $ の使用を強要されてるせいもあるとおもう 2010-09-06 04:42:00 えんじに🐈にゃーん💉💉 @uupaa $ はそもそも人が利用する識別子として許されてないってのもデカイです(ECMAScript規約違反)。 著名ライブラリ達は平然と $ を利用していますが、あれルール違反だから 2010-09-06 04:44:25

    ECMAScript 規定: ドル記号は機械的に生成されるコード中のみの使用を意図される
  • https://www.itarchitect.jp/issue/-/124529-4.html

  • BrewersCapTheorem - ブリュワーの CAP 定理

    BrewersCapTheorem - ブリュワーの CAP 定理 目次 この文書について ブリュワーの CAP 定理 - Amazon と eBay のクールエイド ブリュワーの(CAP)定理 一貫性 (Consistency) 可用性 (Availability) 分割耐性(Partition Tolerance) 定理の重要性 図解で証明 CAP と折り合う 1. 分割耐性を諦める 2. 可用性を諦める 3. 一貫性を諦める 4. BASE に跳ぶ 5. 問題をかわして設計する まとめ 参考文献 ブリュワーの CAP 定理 この文書について "Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking" の日語訳です. http://www.julianbrowne.com/article/view

  • Brewer’s CAP Theorem

    We know three chords but you can only pick two On Friday 4th June 1976, in a small upstairs room away from the main concert auditorium, the Sex Pistols kicked off their first gig at Manchester’s Lesser Free Trade Hall. There’s some confusion as to who exactly was there in the audience that night, partly because there was another concert just six weeks later, but mostly because it’s considered to b

  • データに意味を持たせてはいけない - masayang's diary

    Jalopnik経由: 'X' man's tag leads to more than $19,000 in Birmingham parking tickets 米国アラバマ州Birmingham市でのお話。 車の登録番号に「XXXXXXX」を選んだScottie Roberson氏。 なぜか、Birmingham市当局から駐車違反切符総計$19,000(ざっと180万円)をもらう羽目に。 →Birmingham市の駐車違反管理システムでは自動車登録番号標を装備していない車については、「XXXXXXX」を入力する仕組みになっていたから、らしい。 結果、登録番号標なしの車の切符全部を受け取ることになった、と。 データに意味を持たせてはいけない これもCOBOL文化の名残でしょ。 '9999999'で最大値とか。 'XXXXXXX'でデータなし、とか。 NULLという概念がなかった時代から

    データに意味を持たせてはいけない - masayang's diary
    llill
    llill 2009/10/22
    うーん、データなしなら確かにNULLが最適だけど、"データに意味を持たせるな"は飛躍しすぎな気が
  • るびま

    『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、日 Ruby の会の有志による Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0058 号 バックナンバー Rubyist Magazine 0058 号 RubyKaigi 2018 直前特集号 Rubyist Magazine 0057 号 RubyKaigi 2017 直前特集号 Rubyist Magazine 0056 号 Rubyist Magazine 0055 号 Rubyist Magazine 0054 号 東京 Ruby 会議 11 直

  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

  • Latest topics > 他のアドオンと衝突しないように心がけたいし、心がけて欲しい - outsider reflex

    Latest topics > 他のアドオンと衝突しないように心がけたいし、心がけて欲しい 宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行まんがでわかるLinux シス管系女子の試し読みが可能! « ツリー型タブとVimperatorが衝突する Main 中学生男子のおっぱいへの情熱に溢れた青春映画「おっぱいバレー」 » 他のアドオンと衝突しないように心がけたいし、心がけて欲しい - Apr 17, 2009 「次のエントリで書く」なんて予告じみたことを書いてはみたものの、どうも話がまとまらない。もう、思ったことを箇条書きで書くだけにする。 現実的に言って、1つのアドオンであらゆる人のニーズを満たすことは不可能だと思うし、そういう方向での努力はしない方がいいとも思う。何でもかんでも……と際限なく詰め込んで

  • Perlゼミ(サンプルコードPerl入門)

    Perl入学式 全6回のPerl入門講座。東京、大阪、沖縄、札幌で開催。(東京は4月と10月スタート、それ以外は5月スタート) YAPC::Japan Perlを軸としたITに関わる全ての人のためのカンファレンス。 東京 吉祥寺.pm 五反田.pm 大阪 なにわPerl 沖縄 沖縄.pm

  • Firefoxの開発者にはUIの設計という事に対するポリシーが欠けている :outsider reflex

    Latest topics > Firefoxの開発者にはUIの設計という事に対するポリシーが欠けている 宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行まんがでわかるLinux シス管系女子の試し読みが可能! « 察する力のある、空気を読める人が怖いと感じる Main pab.na2をThunderbirdにインポートできない件 » Firefoxの開発者にはUIの設計という事に対するポリシーが欠けている - Sep 20, 2008 タイトルは半分くらい釣り。 ごく最近入った変更によって、最後のタブを閉じると常にウィンドウ全体が閉じられる、という挙動になったらしい(Firefox 3.1では多分それがデフォルトになる)。この変更はパッチを書いたDão Gottwald氏ではなく開発責任者の一人のMike

    llill
    llill 2008/09/21
    ポリシーを欠いた現場というのはどこにでもあるものだなという感想。無いと来し方を忘れさせ行く末をブレさせる大きな問題なのだけれど
  • 1