タグ

2013年12月10日のブックマーク (2件)

  • Rails 4.0.0を4.0.2にアップグレードした

    Rails 4.0.2が出ていたので、セキュリティフィックスが含まれているということもあって、動かしているウェブアプリ(このブログ)を4.0.2にアップグレードしました。その際の作業ログをメモっておきます。 Rails 3.2.16 and 4.0.2 have been released! http://weblog.rubyonrails.org/2013/12/3/Rails_3_2_16_and_4_0_2_have_been_released/ (1) GemfileのRailsのバージョンを4.0.2にする (2) 以下のコマンドを実施。 {{{code bundle update rake rails:update }}} 以下、rake rails:updateの作業ログです。 -routes.rbはスキップ -application.rbは特に変化が無かったのでスキップ

    Rails 4.0.0を4.0.2にアップグレードした
    akasata
    akasata 2013/12/10
    ブログのRailsのバージョンを最新に上げたので作業ログを残しておきます
  • IDの設計についてのさらに突っ込んだ議論

    今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり(ブログ書いてないで原稿書けよ>俺)であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で

    IDの設計についてのさらに突っ込んだ議論
    akasata
    akasata 2013/12/10
    さんざん失敗したことがある話なので耳が痛いけどw、良い記事だと思う / (Railsは悪くないが)Railsが批判されるのは、設計を経ずに落としどころにたどり着く危険性があるからだと思う