写真でも見えるだろうか？
コロッケの中に入っているお肉からこぼれんばかりの肉汁が…。
130円と少し高めの値段は、口に入れてみたら納得であった。
1365段の階段を登って絶景を見た後は、コロッケで腹ごしらえと。
疲れたあとのコロッケ最高です。
うどん県に来たら一鶴の骨付肉も食べるべし。ジューシーで豪快な肉がたまらない
うどん県、それだけじゃない香川県。
グルメでいえば、この一鶴の骨付肉は「それだけじゃない」の代表格だろう。
写真は、骨付鳥 ひなどり（870円）
これのほかに、おやどり（980円）もある。
ひなどりは肉が柔らかく食べやすい。女性や子供向け。
おやどりは、肉が固めで噛めば噛むほど味がしみでてくる。ビールのつまみぴったりな大人向け。
どちらも食べてみたけれど、それぞれ良さがあって甲乙つけがたい…。値段もお手頃なのでどっちも行ってしまってもいいだろう。
そして、とりの味がしっかり染み込んだ「鶏飯」もうまい。
お肉と一緒にぜひ頂いてみて欲しい。
さらに、小皿も手が込んでいる。この牛すじ煮込みは絶品であった。
牛スジ煮込みうますぎ。
香川名物だが、横浜駅西口にも店舗があるので、東京・神奈川周辺にお住みの方はまずはそちらで。
ハマったらぜひ本場のうどん県へ！
神泉の4席だけのアットホームなあたたかいカレー屋さん「マサカレー」
最近ハマっているカレー屋さんをご紹介。
神泉駅から徒歩5分ほど、外からはひっそりと看板が見える程度。長い廊下を抜けると、わずか4席のアットホームなカレー屋さんが佇んでいる。
店長のマサさん1人で回しているというこのお店。
メニューは、
- マサカレー 500円
- 豆カレー 600円
- トマトチキンカレー 600円
- ミックス 600円
とシンプルかつリーズナブル。
上の写真は、豆カレーとトマトチキンカレーのミックスです。定番のマサカレーも、ひき肉ベースでスパイスも絶妙でハマってしまう味。
営業時間は11:30〜14:00の昼のみと短め。
その理由を聞いてみたところ、1人で全てをこなしているため、夕方から夜にかけては仕込みに時間を割いているそう。
ルーの種類を１つの絞れば夜も営業できるのですが、マサカレーファンの方もいれば、豆カレーファンの方もいますしトマトチキンが好きなかたもいらっしゃるので、作らないわけにはいかないんです。
と笑顔でお話されていたのがとても印象的だった。
渋谷・道玄坂方面にお昼に来られた際は、ぜひ伺ってみてください！
グローバルな視点とはローカルを考えないという訳ではない
先日、とあるデザイン系のイベントに参加した。
参加者同士で話していると、いつの間にか「グローバル化」についての議論になっていた。
初対面同士ということもあったし、その場では少し遠慮してしまったけれど、このままだともやもやするので、僕の考える「グローバルな視点」について、書き残しておくことにする。
その前に、ここでいう「グローバル」を定義しておこう。
global
covering or affecting the whole world
― Oxford Advanced Learner's Dictionary
"全世界を対象にする、あるいは、全世界に影響を及ぼす" といった感じ。もちろん他の定義もあるだろうが、とりあえず本記事では OALD さんの定義で話を進めることにする。
グローバルとは海外に進出することか？
そうは思わない。結果的にそうなることもあるが、それは手段であって目的ではない。そもそも「海外に進出する」と選択肢を絞ることは「グローバル」ではない。なぜなら、そこには「国内」という選択肢が抜けているから。つまり、全世界を対象にしていないのだ。それではグローバルとは呼べまい。
グローバルとは、全世界を対象にする。すなわち、国内も含む。ということは、グローバルな視点とは、国内も海外も全てを対象にして比較分析する視点であると言い換えられるだろう。
海外や自国という境界に囚われず、「全世界」という1つのものとして捉える。それこそ、グローバルな視点と呼べるのではないだろうか。
海外進出は様々なリスクやデメリットがあって現実的ではない？
そうかもしれない。ただ、そう決めつけるべきではないと思う。「海外に進出するからグローバルな視点だ」とも思わないし、「国内でビジネスをするからグローバルな視点ではない」とも思わない。どちらも論点がズレている。
繰り返しになるが、大切なのはもう1つ上のレイヤーで、国内も海外も全てひっくるめてどこがベストなのかを分析しようとする姿勢だろう。
海外進出にはもちろん様々なリスクやコストが伴う。本部が国内にあるとすればコミュニケーションコストは発生するし、進出先の文化や現地の人の特性を知るというコストもある。また、地域によっては、暴動や災害のリスクも高いかもしれない。
それらも全て含めて、コストとして換算すればよい。未知な部分があれば、多めに見積もればよい。そんな簡単にコスト換算できるわけがない？それならば、コスト換算にかかるコストも含めればよい。
そうして様々なコストを算出した上で、「海外がよいのか・国内がよいのか」の判断をすればよいのではないか。実践したことはないので現実味がなければ学生の戯言として流してもらってかまわない。だが、そこまで無理なことではないんじゃないかなと思ったりする。
まとめ
アメリカ留学時代に、「アメリカの大学で感じるグローバリゼーションの兆し。 」という記事を書いた。グローバリゼーションって、もはやバズワードとかそういった特別なものではなくて、生活に関わるところまできていたりする。
「グローバルな視点」で物事を見るクセをつけなければと思った。
Rails3でflashにリンクを組み込む方法
flashでリンク出てきたほうが親切だなと思い、やってみました。
少しだけハマるとこありました。
# users_controller.rb def update link = "<a href=\"#{url_for(:controller => 'users', :action => 'show')}\">#{@hoge.name}</a>" if @hoge.save flash[:success] = "保存されました。#{link}".html_safe redirect_to dashboard_path end end
分かりやすくするため、link 部分を変数にしました。ポイントは以下。
- 'link_to' ではなく 'url_for' で指定してあげる
- '.html_safe' でHTMLがエスケイプしないようにしてあげる（Rails3.x の時）
この2箇所かなと。
'link_to' を controller から利用するには、helper module が必要なので、'url_for' を採用。それから、Rails3では自動でエスケイプ処理が行われる仕様なので、それを'.html_safe'で制御。
おわり！
※ 無理矢理感は否めませんが、まあ動くというレベルですね…
プログラミングと数学の証明の共通点
プログラミング初心者の雑感だけれど、たまにプログラミングは数学の証明と類似しているなーと思います。
両者の共通項は次のような感じ。
- 解くべき問題の条件が与えられており、
- 証明すべき命題（完成形）を示すことが目的であり、
- その道筋は当事者に委ねられている
3点目の、「どのように導くか」という点で技量が試されたりするところも、プログラミングと数学の証明で共通していると言えるでしょう。
高校時代のお話 - たくさんの問題に触れて引き出しを増やすこと
そういえば、僕の通っていた高校は、理系重視の方針もあり在学生の7割ほどは理系だったかなという感じなのですが、クラスで数学の証明なんかをやると、普通なら20行くらい必要なはずのところを、スラっと5行くらいで書いてしまう人がいたりしました。
先生も苦笑い。彼はプログラミングをやらせてもきっと綺麗でスマートなコードを書くんじゃないかなと思います。
そういえば、彼が何をしていたかと思い返してみると、いつも「大学の数学」を解いていた気がします。きっと僕なんかよりずっとずっと多くの問題に触れていました。
「たくさんの問題に触れて引き出しを増やすこと」
数学教師が口を酸っぱくして言っていた言葉がふと蘇りました。
Railsでサブドメイン間でログインを保持するためのセッション設定
Railsでサブドメインにアクセスすると、デフォルトの設定では、ログイン（セッション）が保持されません。
解決策は以下の通りです。
ググると間違った（or 古い）情報も散乱していたので、惑わされないようにそちらも一応のせておきます。
session_store.rbの設定
session_store.rb で以下のように設定します。
# session_store.rb Appname::Application.config.session_store :cookie_store, key: '_user_session', domain: 'example.com'
少し解説すると、
domain: 'example.com'
のように、domainを指定するのがポイント。
production, staging, development で以下のように分岐してあげればいいかなと。
if Rails.env.production? Appname::Application.config.session_store :cookie_store, key: '_user_session', domain: 'example.com' elsif Rails.env.staging? Appname::Application.config.session_store :cookie_store, key: '_user_session', domain: 'staging-example.com' else Appname::Application.config.session_store :cookie_store, key: '_user_session', domain: 'lvh.me' end
ちなみに、stagingで用いている 'lvh.me' は、127.0.0.0 に割り当てらているドメインです。localhost だとサブドメインのチェックはできないので、lvh.me はすごく便利。
domainオプションを追記する際には、keyも変えるべし
ここはハマったところなのですが、domain: 'example.com' を追加すると、セッションの情報も変わります。しかし、keyの名前は同じ。
すると、既にログインしていたユーザーがログアウトできなくなるなどの不都合が生じてしまう可能性があります。（実装にも依ると思いますが）
なので、domainオプションを追加するタイミングで、session_key の名前も変更しておいたほうが無難だなーと思います。
関連記事
Railsでカスタムサブドメイン-本サイトとサブドメイン間のURL設定
Railsでサブドメインを実装した際に、本サイトとサブドメインサイト間の受け渡しで少しハマりました。
サブドメインサイトにいる状態で、root_path や root_url でリンク先を指定しても、本サイトではなく、そのサブドメインのトップに飛ばされます。
この記事では、url_for メソッドを利用して、サブドメインサイトと本サイト間を行き来する方法をご紹介します。
url_forでメソッド作成
subdomain_url_helper を以下のように作成
module SubdomainUrlHelper def with_subdomain(subdomain) subdomain ||= 'www' subdomain += "." [subdomain, request.domain].join end # - remove subdomain and go to the original site # url_for(:subdomain => false) # - go to the specific subdomain site # url_for(:requested_subdomain => 'subdomain') def url_for(options = nil) if options.kind_of?(Hash) && options.has_key?(:subdomain) options[:host] = with_subdomain(options.delete(:subdomain)) elsif options.kind_of?(Hash) && options.has_key?(:requested_subdomain) options[:host] = with_subdomain(options.delete(:requested_subdomain)) options[:controller] = 'users' options[:action] = 'show' end super end end
メインは、2つめのurl_forメソッド。
with_subdomainメソッドは、引数の subdomain と request.domain を合わせるためのもの。なお、subdomain が存在しなければ、www が代わりに入る。
そのため、
url_for(:subdomain => false)
とすると、
# if request.domain is "example.com"
www.example.com
のようになる。
url_for については、渡された hashのkey で条件分岐してあるのは、見ての通りです。
コードがなかなか汚いのでだれかリファクタお願いします。
関連記事
Railsでカスタムサブドメイン機能を実装する時のルーティング設定
運営中のサービス「BoxToYou（https://www.box2you.com）」でカスタムサブドメイン機能をリリースしました。
いくつかハマったところがあったので、数回に分けてメモしていきまする。
今回は、routingの設定とリンクの設定方法について。
サブドメインの条件定義
まず、subdomain.rb でサブドメインの条件をかきかき。
#subdomain.rb class Subdomain def self.matches?(request) request.subdomain.present? && request.subdomain != "www" end end
RailsのRequestオブジェクトにsubdomainメソッドが定義されているので、
request.subdomain
という風にリクエストのサブドメイン部分「http://◯◯◯.example.com」の◯◯◯を簡単に呼び出せます。ただし、「www」もサブドメインとして処理されますので、カスタムサブドメインの設定としては不適切として、
request.subdomain != "www"
という風にmatchの条件から排除しています。
ルーティングの設定
次に、routesファイルの設定。
#routes.rb # routes setting of subdomain # should be placed above the "root :to" path require "#{Rails.root}/app/helpers/subdomain" constraints(Subdomain) do match "/" => 'users#show' match "/*a" => 'application#render_error404' end # other routes settings root :to => "users#index" #
上記のsubdomain.rbを読み込み、
constraints で条件がマッチした際には、別のactionに飛ばすようにしています。
match "/" => 'users#show' match "/*a" => 'application#render_error404'
については、アプリの仕様で、root_path の後ろには何も来ない場合の処理です。404 error のページへ飛ぶようにcontroller側で設定しています。
コントローラー側の制御
ちなみに、subdomain の controller 側の処理はこんな感じです。
# users_controller.rb # if no users exist who has the requested.subdomain, # redirect the request to the top page. unless User.where(:subdomain => request.subdomain).present? return redirect_to url_for(:subdomain => false) end # specific a user from request.subdomain @user = User.where(:subdomain => request.subdomain).first
リクエストされたサブドメインを持ったユーザーが存在しなかった場合は、トップページにリダイレクトしています。
url_for(:subdomain => false)に関しては、subdomain_url_helper.rb というヘルパーを作って設定しています。（詳細はこちら）
そして、次に、subdomain は各ユーザーがユニークで持てるようにしているので、
@user = User.where(:subdomain => request.subdomain).first
で特定のユーザーを特定して、インスタンス変数に入れています。
こんな感じで、だいたいの設定はできるかと。
関連記事
参考記事
Rails - mockを使って1つの属性のみにvalidationを走らせてみる
ユニークなユーザー名やサブドメインを付与するときに、ajaxで入力されたその場で有効な値かどうかを判断してあげれば、ユーザビリティは向上するだろう。ツイッターなど大規模なウェブサービスでは実装されていることが多いかと思う。
しかし、.valid? メソッドを使ってしまうと、そのオブジェクト全体にvalidationがかかってしまい不都合が生じてしまうので、今回は、1つの属性に対してvalidationをする方法について扱う。
具体的には、以下のように、検証を行いたい1つの属性を持った新しいオブジェクト（ここでは、mock）を作り、mock.valid? でエラーを発生させ、そのエラーに調べたい属性のkeyがあるかどうかを見る。
def valid_attribute?(attr, value, present_username) mock = User.new(attr => value) unless mock.valid? if mock.errors.has_key?(attr) && value != present_username return false else return true end end true end
attr が調べたい属性の名前、value がその属性に与えられた値。
さらに、ここでは、ユーザーネームの検証を行うと仮定して、present_username という引数を与えてみた。
ポイントは、
mock = User.new(attr => value)
で、ユーザーが入力した値を用いて、新しいユーザー mock を擬似的につくり、
unless mock.valid?
で、エラーを発生させ（全ての属性の検証にクリアすれば true が返る）、
if mock.errors.has_key?(attr) && value != present_username
で、エラーに attr という key があり、かつ、入力された値 value が現在のユーザーネーム present_username と異なる、という条件で value が不正な条件を作り出している点。
個人的に、mock をつくるのと、errors.has_key? を使うあたり、勉強になった。
色んな方法があるのだなーと。
参考にしたのは、stackoverflow の以下の記事。
Is there a way to validate a specific attribute on an ActiveRecord without instantiating an object first?
また、ActiveRecord を使用している場合は、以下の記事で触れられている方法が使えそう。
Rails - 状況によってsave時に実行するバリデーションを切り替える
view側の実装は別記事にする予定。
