タグ

ITとdbに関するkraken_eyeのブックマーク (6)

  • SQLインジェクション対策漏れが重過失認定された判決文を読んだメモ | F's Garage

    徳丸さんの記事をたどって、判決文読んだ。 SQLインジェクション対策もれの責任を開発会社に問う判決 | 徳丸浩の日記 技術面に限った僕的解釈メモ(あくまで個人的な読書メモですので、正確な内容はこちらをご参考ください) ・カード番号の保存は、売り掛け金についてのカード業者を特定するための仕様追加。 ・決済業者へのリンク型の決済を、自社サーバ経由の決済に切り替えた時に全てのカード情報を保存していた。 ・管理画面には、カード情報の一部しか表示されない仕様になっていればよかったのに(カード番号先頭6桁で把握可能)、なぜか律儀にセキュリティコードまで保存されていた。 ・さらにログファイルにも個人情報やカード情報が保存されていて、さらに外部から参照可能になっていた(これが直接の流出原因とはされていない) ・特定の機能について適切にSQLをエスケープしておらず、そこにSQLインジェクションをつくアタック

    SQLインジェクション対策漏れが重過失認定された判決文を読んだメモ | F's Garage
  • 主キーはインデックスではない - 設計者の発言

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

    主キーはインデックスではない - 設計者の発言
  • 達人の技芸を継承する方法はこの世に存在するか? - give IT a try

    前回投稿した「技芸(アート)における経験の重要性」というエントリを改めて読みなおしてみると、「誰も第二の倉貫さんにはなれない」とか、「と同じパンは誰にも焼けない」とか、見方によっては救いのない印象を与えたまま終わってしまったのが、ちょっと残念だったかな〜と感じました。(自分の書いた文章ながら) まあ確かに、達人の技芸を完璧に継承することは不可能だとは思います。 ですが、ちょっとでも近づいたり、達人の心意気や考えは取り入れつつ、その人独自の路線で進化(深化?)させたりすることは可能なんじゃないかとも考えています。 ちなみに、プログラマであれば、以下の2冊にそれらしきヒントが見つかるかもしれません。 (というか、久々に棚から引っ張りだして読んでみたら、前回のエントリに結構内容がかぶっていました。別に意識して書いてたわけじゃないんですけどね) ソフトウェア職人気質―人を育て、システム開発を成

    達人の技芸を継承する方法はこの世に存在するか? - give IT a try
  • @nippondanji 氏の「データベース設計徹底指南!!」は神プレゼン!脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件! - #garagekidztweetz

    ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました! 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース(以下RDB)は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で

    @nippondanji 氏の「データベース設計徹底指南!!」は神プレゼン!脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件! - #garagekidztweetz
  • 行ってもいないOracle OpenWorld 2013の感想は「オラクルにはクラウドよりヨットがお似合い」

    さて、秋のITイベントでいちばん話題になるものといえば、ご存じ、サンフランシスコの街を真っ赤に染めるOracle OpenWorldです。DB Onlineにも谷川チーフの記事がたくさん掲載されていたので読まれた方も多いと思います。筆者は今年、参加することはできなかったので、OOWを総括する意見を言う立場にないのは承知ですが、個人的にはOOW最大のニュースが「ラリー・エリソンCEOがキーノートをぶっちぎってヨットレース(America's Cup)の応援に行った」ということをひどく残念に思っています。CEOが自社イベントのキーノートをぶっちぎった、そのこと自体もがっかりですが、それよりもオラクルがクラウドビジネスにどれだけ気で取り組もうとしているのか、顧客や投資家に対して示す最大のチャンスをCEOみずからが放り投げたという事実に、当に落胆させられました。 ラリー・エリソンがぶっちぎった

    行ってもいないOracle OpenWorld 2013の感想は「オラクルにはクラウドよりヨットがお似合い」
    kraken_eye
    kraken_eye 2013/11/05
    タイトルが。
  • 大規模SIは少数精鋭で乗り切れるのか? - 急がば回れ、選ぶなら近道

    まず現状の認識は以下の通り 1.20-30代の就業人口の減少これは大前提になる。 また情報共有も進むためよりブラックな会社が 人を集めること自体のハードルがあがる。 結果として、人員を集めるということがより厳しくなる。 これはITに限らず、労働集約的産業全体の課題でもある 2.能力格差の拡大今の40-50代よりも間違いなく、現状の20-30代は 勉強している人としていない人の格差は広がっている。 ゆとり云々とは別に、社会的なプレッシャーから、 むしろ勉強しないと勝ち残れないという強い意識のある集団と、 ゆるふわほんわか草集団の差が非常に非常に広がっている 3.資源の拡大要するに、割とハード・リソースに余裕が出てきている まず、クライアントサイド。 要はなんでもできる状態になりつつある。 jsあたりはほぼ無法地帯の感もある。 一時、jsでOSみたいのまでいけるぜ、というデモもあったが 技術

    大規模SIは少数精鋭で乗り切れるのか? - 急がば回れ、選ぶなら近道
  • 1