>>向こうの人は、目が黒いっておかしいっておもってるのかね? 人類の中で最も多い色だからそれはない 白人がみんな色付きの目してると思ってんの?
>>向こうの人は、目が黒いっておかしいっておもってるのかね? 人類の中で最も多い色だからそれはない 白人がみんな色付きの目してると思ってんの?
2024.02 « - - - - - 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 - - - - - - » 2024.04 DBテーブル間の関係としては、3種類ほどありまして、 ケース1 テーブルAの1レコードに対してテーブルBの1レコードが対応 ケース2 テーブルAの1レコードに対してテーブルBのたくさんのレコードが対応 ケース3 テーブルAのたくさんのレコードに対してテーブルBのたくさんのレコードが対応 とあります。Rails はそれぞれをモデルファイルで指定できます。 前回のエントリの都道府県テーブルと市区町村テーブルは、上記のケース2にあたりますね。 普段のエントリに漏れず、やはり例が分かりやすいと思うので、上記の3ケースの例を書いてみます。 ケース1 都
エンジンのマイグレーションをコントロールするのにマイグレーションをつかうにはどうすればいいんだろう?言い換えると、通常のマイグレーションから rake engine_migrate を呼ぶにはどうすればいいんだろう? 初めから全部Rubyコードでモデルを書きたいと思ったら、最初のDBスキーマ定義からこれが使えるってこと? そう、使える。 いろんなデータベース向けに何種類ものSQLファイルを作るよりずっと簡単だから、僕はこのすばらしい方法を使ってる。 -- MattMoriarity? A migration is run with the current model. Older migrations may fail when depending on a newer model. そのとおり。 例えば、マイグレーション003がArticlesテーブルに行を追加したいのに、そのテーブル(
ドキュメントを読むとchange_columnは項目型を変更するもと書かれていて、長さの変更は出来ないのかなと思いましたが、他に適当なメソッドも無さそうだったのでやってみると、(:limit=>32 指定だった 'name' を :limit=>255 に変更) def self.up change_column :users, :name, :string, :limit=>255 end 全然OKでした。まぁ長さ変更も型変更のうちですしね。 この場合、逆変換は破壊的変換になるので、ドキュメントに従えば自動では行わず、 def self.down raise ActiveRecord::IrreversibleMigration end とするのが行儀がよいということでした。
コンテンツへスキップ 無料で使える!HubSpotの顧客リストの活用法 無料のアンケート作成ツール 比較/まとめ 無料「Excel」 テンプレート 比較/まとめ 無料で使えるノートアプリ比較 (Evernote / OneNote / Google Keep) おすすめの無料Web会議システム5選 WebP Converter 徹底解説!初心者でも直ぐに使える HubSpot は、マーケティング、セールス、サービスのためのCRM(Continue reading 多くの人の声を聞くことで改善できることも多い 企業や団体など運営していContinue reading 就職・転職には必須となる履歴書・職務経歴書 これから就職活動をスタートContinue reading 便利なノートアプリで効率的な仕事をしよう いつの時代も仕事をしていてメContinue reading 近年、リモートワーク
This domain may be for sale!
CatalystのStatic::SimpleとSessionの相性が悪い CatalystのCatalyst::Plugin::Static::SimpleとCatalyst::Plugin::Session(::State::Cookie)の相性が悪い。最悪の場合セッションキーが消されてしまう。 原因はprepare_actionの実行順で、解決策としてはプラグインのロードの順番なのだが、 use Catalyst qw/Static::Simple Session/ とした場合、 prepare_actionはStatic::Simpleの方が先に実行される。ところがStatic::Simpleのprepare_actionは、 return $c->NEXT::ACTUAL::prepare_action(@_); で終わるため、Sessionではなく、SUPER:: prepar
とあるアカウントでメールを受け取った際に、perlを実行する為にエイリアスに追加した。 #vi /etc/aliases foo: "|perl /home/foo/bar.pl" #newaliases これだけだと、メールが返ってきて以下の内容で怒られる。 The original message was received at Mon, 4 Sep 2006 11:15:55 +0900 from [192.168.1.XX] ----- The following addresses had permanent fatal errors ----- "|/home/foo/bar.pl" (reason: Service unavailable) (expanded from: <foo@domains.jp>) ----- Transcript of session follow
2007/06/24 Rails Migration Migrationは物理的なデータベースによって使われるスキーマの変更を 管理するためのものです。新しい機能のために、 データベースにフィールドを追加する必要がある時 他の開発者にどのように変更を伝えるか、 商用サーバにそれをどう適用すればよいかを 伝えるための共通の問題に対するソリューションです。 Migrationを使う事で、変更をクラスとして記述する事ができ、 バージョン管理システムで管理し、他のデータベースに対して 1、2または5つ以上のバージョンを適用することができます。 Migrationの簡単な例は次のようにものです: class AddSsl 1 end def self.down remove_column :accounts, :ssl_enabled end end このMigrationはaccountテーブルに
メールが届くと同時に何らかのアクションを起こすプログラムというのは、かなり作る機会の多い部類に入るかと思います。 ここ数年で特に多いものだと、ケータイ向けサイトの案件で、空メールを受信したら自動でユーザー登録用のフォームのアドレスを書いたメールを、空メール送信者に送る、みたいなものとか、ブログやSNSの日記なんかを、ケータイメールで投稿できるようにする処理とかですね。 そして王道の自動返信メールとか。 後、途中で飽きちゃったんですが、昔、送られてくるメールの内容を自分で学習して言葉を覚えて、文章を生成して返信する bot (人工無脳)を趣味で作ってたことがあります。 で、実際こういう「メールを受け取ったら何らかの処理を自動で行なう」という機能を実現するには、どうすれば良いかというと、 特定のメールアカウントにメールが届いた際に、何らかのプログラムが起動するように設定する そのプログラムを書
Rails には、アプリケーションのモデル・コントローラの内容や関係が記述されたクラス図を、リバースエンジニアリングして生成してくれる RailRoad という便利なツールがあります。 設計は軽くすませて、すぐにプログラミングしていくことが多い Rails アプリケーションですが、全体像を把握したい場合や、他の人に見せたい場合などは、こういうツールがあると便利ですね。 というわけで、実際に使ってみました。 インストール Graphviz をまずはインストール railroad をインストール gem install railroad Rake タスクとして実行できるようにする lib/task/diagrams.rake namespace :doc do namespace :diagram do desc "Generate Model diagrams." task :models
マイグレーション、やればやるほど便利ですね。 単純に、テーブル操作だけじゃなくて、ファイル保存先の変更とか、内部仕様の変更に対しても使えそうな印象を受けます。 基本的なやり方・書き方は、巷にあふれかえっていたので、そこは調べていただくとして。 今回は、特に、マイグレーションでの外部キーの設定の仕方について、メモ。 マイグレーション、基礎 そもそも、マイグレーションってどうやるの?って人は、以下のところを参照されるとわかりやすいかと思います。 RoR Wiki 翻訳 Wiki – UnderstandingMigrations RoR Wiki 翻訳 Wiki – UsingMigrations ヽ( ・∀・)ノくまくまー(2005-08-17) Rails Wiki – migration FFTT : RailsのMigration 1 : SQLを利用する場合 ひとつめのやり方として、
ロック読み取り (SELECT ... FOR UPDATE および SELECT ... LOCK IN SHARE MODE)
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
[Catalyst] 知らなかった ex) http://catalyst.g.hatena.ne.jp/lapis25/20070806 ex) http://search.cpan.org/~jayk/Catalyst-Plugin-Authentication/ 試してみる $ vim lib/MyApp.pm use Catalyst qw/ (略) Authentication Authentication::Store::DBIC Authentication::Credential::Password /; ↓ use Catalyst qw/ (略) Authentication /; $ vim myapp.yml authentication: dbic: user_class: MyAppDB
通常、MySQLでは、selectコマンドを実行した場合、1レコード目から最終レコードまで、シーケンシャルに検索を行っていきます。 しかしながら、レコード数が大量になってくると、検索速度の問題が生じます。 そこで、より高速な検索を行うために、インデックスを作成するのが一般的です。 インデックスを作成することによって、検索速度は劇的に改善されます。 但し、MySQLでは、1,000件以下であればシーケンシャルに検索した方が速いとされています。 さて、インデックスとはどのようなものであるかというと、直感的には、図書の巻末に付されている索引(インデックス)と同じです。 索引語はアイウエオ順、あるいは、アルファベット順に並べられていて、各々の索引語には、その索引語が登場するページ数(位置情報)が示されています。 読者はその位置情報を頼りに、ページを捲って、目的のキーワードのある部分を読
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く