Google Driveが使えるようになりました

今朝Google DocsにアクセスするとGoogle Driveが使えるようになっていました。

https://drive.google.com/

同サイトからMac用のクライエントソフトも導入して、FinderからGoogle Docsのファイルがみれる様になりました。ドキュメントをダブルクリックするとブラウザが立ち上がり、Google Docsのファイルが表示されます。

ロッテリアのコーヒーがマグカップで飲めるようになってました

今日は郵便物を出す用事があったので外に出たついでに、宝塚駅前のロッテリアでコーヒーを頼み少し外で仕事をしました。

以前は紙コップしかなかったのが嫌だったのですが、今日は行くと最近マグカップを始めたと店員さんが教えてくれました。企業努力で今よりもっと良くという姿勢が私は好きですね。

 

 

篠山って面白いところが沢山ありそうです

 

最近縁があって篠山に遊びに行くことが多いです。

今日は篠山で町おこしをやっている人達がいるという記事を見つけ、その記事に出てきた場所の一つである中国茶のお店に家族で行ってきました。記事が載っていたのは http://plus-note.jp/live/

 

"ことり"という中国の岩茶と点心を出しているお店で、ゆっくり時間を過ごせたように感じました。たまにはこんな風に優雅にお茶を飲むのは良いです。優雅と言ってもお金は多くかかりませんが。

お茶屋さんは篠山城の近くでJRの篠山口駅駅からは少し離れていますが、駅からはバスが出ていますし、それ以上に私が便利だと思うのは自転車を借りられることです。子供を乗せられる自転車も借りられるので便利です。自転車だとお城まで20分程度で着きます。

また、茅葺屋根のイタリアレストランも見つけました。ここは昼は大抵予約で一杯になるとか…。篠山の田舎なのにすごいですね。

なんでも篠山には最近ギャラリーがたくさんできたり、ブリキのおもちゃをつくれるもとおもちゃ工場の小さな博物館があったりするそうです。また遊びに行きたいです。

 

ギルガメッシュ叙事詩を歴史の扉として

ギルガメッシュ叙事詩に興味を持ったので、子どもと一緒に読める絵本版の「ギルガメッシュ王ものがたり」と続編の2冊を借りてきました。

 

叙事詩とは民族の歴史の大切な出来事を詩の形で書き残したものです。このギルガメッシュ王叙事詩は、5000年前のメソポタミアで粘土版に書かれたものが時代によって書き換えられたりして伝えられたものです。

 

昔の人たちがどんな出来事に一喜一憂していたのかを感じることによって、メソポタミアやその周辺の歴史についての思いをはせることができます。聖書やイスラム教、ユダヤ教にも出てくるノアの方舟の物語も登場します。これらの宗教の起源をにももっと興味が湧きますし、現在のパレスチナ周辺の紛争についても現代の利害のための闘いという見方だけでなく、もっと深い民族的根元がみえてくるかもしれません。

気づきのヒントはこんなところにもある

Aloneという言葉の語源はall aloneだということを目にしました。everyoneではなくallone。本当の意味で一人になることは、孤立するということではなく全てが一であるということをこの言葉を作った人/社会が認識していたのかもしれません。これはすごい洞察だと思います。

また、Aloneという状態を表す言葉とlonelyというイメージを表す言葉が混同されて多くの場合使われているのではないでしょうか。本来の意味でのaloneになるのはとても魅力的ですね。

ただの語源を探るだけの事ですが、その背後にはその時代に一生懸命生きた人の叡智が隠れているんでしょう。

タグとカテゴリーの違い

タグとカテゴリーってどう違うの？と訊かれたのですが、私自身よく分からないままに使っていました。下に私の調査と考察の結果をまとめてみます。

概念：例えばブログの場合カテゴリーは本来親カテゴリの中に子カテゴリがあり、その中に何かの記事があるという階層がある入れ子の構造を構成するもので、ある記事は一つのカテゴリーに属しているはずです。最近のブログプラットフォーム(例えばWordpress)では一つの記事がいくつかのカテゴリーに属せる様になっているので、本来のカテゴリーの概念よりタグの概念に近くなっている気がします。数学やロジックといった”理論”の系統に属する概念だと思います。一方タグはフレキシブルで、概念としては目印を付けるというだけなので、使い方次第でかなり何にでも使えると思います。本の整理をするのであれば未読の本に印を付ける、母親の本に印を付けるなど、全然関係の無い分類の仕方でも印（タグ）を付けられると思います。

ウェブでの使用方法：タグの概要としては上のようにどのようにでも使えるのですが、ではどのように使うのが良いのか？という話を私の観点でします。私の知っているタグの見せ方は主に２つ。一つはタグクラウドの方法で、これは例えばブログの著者の記事にどの様なものが多いかという傾向が見えます。また、Twitterのハッシュタグクラウドでは今どのような話題が人気があるのかという分析もできます。この方法を使用するのであれば、記事を書く度に思いついたキーワードをタグとして貼付けていく形になると思います。もう一つはユーザが興味のある話題のタグを設定してカテゴリーとは異なった分類の仕方を提供する方法です。これであればブログの運営を始める前に、まずユーザが興味のありそうな話題を洗い出してタグを作っておき、記事を書いた時にそのなかから選択してタグを貼付けていく方法になると思います。

実際にどう使い分けるか(例えば会社の経営者のブログなどの場合)：

- カテゴリーは業務内容の分け方で分ける。
- タグの使い方は、ソーシャルなサイト（例えばTwitterやFacebook,Flickrなど）であれば現在の傾向が見えるタグクラウドの形式での見せ方が良いと思いますが、個人や一つの会社であれば傾向に興味がある人などまずいないと思います。そのため、私はまず読者が興味のありそうな話題を洗い出してタグを記事に割り振っていく形が良いと思います。現時点でまだ読者が何が欲しいか分からないという状況であれば、まず半年程度記事を書く毎にキーワードのようにタグを付けていき、ある程度どのような記事に訪問者の興味があるか、また自分がどのような記事を書くかという分析の為にデータをためるという方法も考えられます。


そういう私が自分で書いているこのブログはかなりカオスな状況です。現時点でいろんなアイデアがうかんで、システム構築、マーケティング立案、チームの調整などの業務に加えて子育てなどの家事もあるため、自分でもカオスには感じています。フリーランスの視点やもっと日本にとらわれない視点など発信していきたいとも思っています。ただ最近になって自分のブログのタグを見ていてこんな記事を多く書いているとか、記事ごとのアクセス数も一緒に見てみて訪問者は主にこのような記事に興味があるという傾向は少しずつ掴めてきています。カオスなブログですが方向性を探っている人たちの参考になったり、良いこともあります。

野菜の季節が近づいてきました

庭にトマトとナスの苗を植えました。

 

暖かくなり、本物の農家の方ではそろそろ関西でも収穫できる野菜がでてきて忙しくなってきている頃でしょう。

 

気分が良くなり料理もたのしくなってきたのですが、あまり時間のかかる料理をつくるとできる前に娘のお腹が空いて大変なことになってしまうので、難しいところです。

 

 

Web広告媒体調査

今日はひたすらWeb広告媒体を調べています。様々な種類がありますね。

まずは、http://mediaradar.jp/ を参考にしてメディアを閲覧しましたが、行動ターゲティング広告やバイラル広告などの項目が気になります。

 

一般に親近感を持ってもらえる商材であるかその周りに親近感の持てるコンテンツを用意していればブログやソーシャルの広告が面白いと思いますが、 私が今担当している商材はまだバイラル系を活用するには準備が必要そうです。最初はリスティング広告、バナー広告、あとターゲットを絞っためーるの広告に予算を分けて様子を見るのがベストかと思います。



やはりソーシャルのコンテンツを用意できると展開の幅が広がるので、準備は早くしていきたいです。



私は広く情報を集めるのがまだ得意でないので、ちょっと効率が上がらないのが難点です…。

春ですね

今日は心地よいので外で仕事です。雨も降る気配が無いので、wifiとモバイルデバイスで暫く仕事ができそうです。

 

宝塚ガーデンズにて。

 

belongs_to とクラス名指定

Railsでアプリケーションを組んだ時に、データベースのアソシエーションで少し苦労をしました。モデルの belongs_to でアソシエーションができません。

Wordpressを組んでいたときの習慣から管理者でログインして作業をする内容は /admin 以下に設置する設計で組みました。コントローラだけではなく、管理に関するモデルまで /admin の下に作りました。Railsの通常のアプリケーションの規約ではこのような設計はしないらしく、RESTが自動でモデルまで探してくれないことが原因で、規約にそって設計をしていれば

belongs_to :model_name

と記述すればアソシエーションが構築されるのですが、規約に従っていないためにクラス名を指定しないといけないということを minami.rb の業務後ティータイムで @yalab さんに教えてもらいました。

/admin 以下にモデルを作成した場合、正しくは

belongs_to :model_name, :class_name => 'Admin::ModelName', :foreign_key => 'id_column_name'

だそうです。

なぜそれが分かったのかという質問をしたところ、クラスのソースコードを読んである程度推測して分かったのだとか。

私が問題にぶつかったときはいつもGoogleでキーワードにエラーログのメッセージをタイプしてユーザフォーラムやブログ記事を見に行きます。でもこうすると結局解決しなかったスレッドがあったり、Rails/Ruby/pluginなどのバージョンが違ったりしてかなり記事を探すのに時間がかかります。ソースコードを読んでその中のドキュメントやソースコードを理解すれば、例えばサーバの設定やインタープリターなどのもっと深いところに問題が無い限りほぼ確実に解決します。

ソースを読むという習慣や感覚を身につけるのは時間と気力がいると思いますが、場当たり的に問題を解決しないのが実際は近道であるということを学べたのが、belongs_to の問題を解決できたことより大きな収穫でした。

Paperclip チュートリアル

Railsのプラグインであるpaperclipはデフォルトでユーザのモデルなどにアバターの画像を一つ挿入するなど、一つのエントリーに対して一つの画像をアップロードして挿入する構造になっています。ブログなどの記事に複数の記事を導入する際はpaperclipを使用してまず一つ画像用にモデル（たとえばasset）を作成し、複数のモデル(assets)に記事のモデルを一つをくっつける必要があります。チュートリアルビデオは
http://emersonlackey.com/screencasts/rails-3-with-paperclip.mov
にありますが、Railsのバージョンの違いなど若干異なる点があったり、ビデオの中で紹介されている nifty-generators gem は paperclip を使うためだけであれば必要ないなどの項目は省いています。

#---------------------

以下手順

#---------------------

新しいアプリケーションを作成

$ rails new myapp

最低限のブログのモデルをscaffoldを使って作成して、rakde で dbも作成

$ rails g scaffold Post title:string content:text
$ rake db:migrate

サーバを開始してアプリケーションができていることを確認。

$ rails s

ルートのリンクをブログアプリケーションのindexにつなげるため、config/routes.rbを開いて次の行を追加。

  root :to => 'myapp#index'

PaperclipをGemfileに追加。

  gem 'paperclip'

そして bundle install を実行。

$ bundle install

画像ファイル用のモデルを作成（suffixの部分の形式はpaperclipがデフォルトで用意しているので変えないように。）

$ rails paperclip model Asset asset_file_name:string asset_content_type:string asset_file_size:integer asset_updated_at:datetime post_id:integer

dbを作成

$ rake db:migrate

Assetモデルのリレーションを決めるため、次の行を app/models/asset.rb に挿入。デフォルトでは/public/system/の下に画像が保存されるので、これを /public/article/ 以下のフォルダに変更。

  belongs_to :post
  has_attached_file :asset, :styles => { :large => "640x480", :medium => "300x300", :thumb => "100x100" }, :url => "/article/:class/:attachment/:id/:style/:basename.:extension", :path => ":rails_root/public/article/:class/:attachment/:id/:style/:basename.:extension"

Postモデルのリレーションを決めるため、次の行を app/models/post.rb　に挿入

  has_many :assets
  accepts_nested_attributes_for :assets, :allow_destroy => true

新しいリレーションを作成するため、postのコントローラの def new と def edit に次の行を追加してサーバを再起動

  5.times { @post.assets.build }

記事を編集・作成するページに画像挿入のフィールドを挿入する。 app/views/_form.html.erb に下の行を追加

  <%= f.fields_for :assets do |asset_fields| %>
  <div class="field">
<%= asset_fields.file_field :asset %>
  </div>
  <% end %>

ここでImageMagickをインストールする必要があるとエラーが出たので、 http://www.imagemagick.org/script/binary-releases.php#macosx の指示に従ってImageMagickをインストール。

表示される画像添付フィールドの数が多いので、これを調整するために app/views/posts/_form.html/erb の一部を if で囲む

  <%= f.fields_for :assets do |asset_fields| %>
<% if asset_fields.object.new_record? %>
<p>
<%= asset_fields.file_field :asset %>
</p>
<% end %>
  <% end %>

dbに登録されている画像を表示。新しく登録するために作成した空の画像を表示しない様に unless 文を使用。画像削除用にdestroyメソッドを利用するcheckboxも用意する。

<% unless asset_fields.object.new_record? %>
<p>
 <%= link_to image_tag(asset_fields.object.asset.url(:thumb) ), asset_fields.object.asset.url(:original) %>
 --> Delete this image. <%= asset_fields.check_box :_destroy %><br />
 <%= asset_fields.object.asset.url(:medium) %>
   </p>
<% end %>

以上でブログの記事に画像をアップロードして貼付けることができます。このブログ記事ではスペリングミスなどできるだけ無いように書いたのですが、もしかすると一部コードなどにミスがあるかもしれません。各自RailsやWEBRickのメッセージと相談してやってみてください。

ジャンベの皮を張りたい

そういえば、知り合いのアジア雑貨ネットショップで購入してからたまにジャンベを弾きます。

音がちょっともさっとしていて、まあこんなものかなと思っていたのですが、最近ジャンベは皮を張らないといけないということを教えてもらいました。そんなことができるとは全然知らなかったです。また、皮を張ってくれる店もあるということでした。こんなことも全然知りませんでした。

ジャンベの皮を張ってくれるお店は三宮の Metri というアフリカ雑貨のお店。行き方は教えてもらったもののなかなか電話はつながらないし、ウェブサイトも情報を伝えたくないのかというぐらい情報が見つからない構造をしています…。ちょっと作り直してあげたいと思いますが、それより自分のカオスなブログをなんとか収拾を付けるのが先ですかね…。

三宮の駅から歩いてすぐなので、今度行ってみようと思います。音がきれいになるかもしれないと思うと楽しみです。

仕事の成果の基準を”時間”意外に移す必要性

最近意識しないうちに、自分が朝９：００もしくは８：００から仕事を始めて夕方５時／６時まで仕事をするという時間を消化する行為自体に仕事の充実感を見つけていたことに気がつきました。確かに時給で仕事をしている人や、自分の成果がどれだけ収益を産むか見れるポジションに無い人にとって他の基準を導入するのは難しいかもしれません。しかし、成果を出して始めて評価されるべきポジションで仕事をしている人にとってこれは全く意味がないですね。１週間に４時間仕事をして十分な成果を出すだけの工夫ができればそれがベスト。後の時間は趣味のスポーツをしたり、家族と一緒に旅行をして過ごした方がよっぽど良い。

自分で自分の仕事を評価する基準は、例えば充実感とか、社会の貢献度など、個人により様々な基準があると思います。すぐに利益を出さなくとも将来的に大きな可能性がある、また自分の仕事は大きな会社の事務の一部だなど、基準を明確にするのは必ずしも簡単ではないと思います。自分の仕事が自分が仕事を一緒にしている同僚やパートナーにどれだけ収益をもたらすかというのも、最低源の基準を設定するのに役に立つと思います。例えば給与をもらっている量の最低1.5倍は収益をもたらす様にするなどです。この基準を元に仕事をすると、自分で設けた設定にいかに効率良くたどり着く方法がベストかを考えます。時間をいくら割くかはある意味重要ではなくなります。

上記給与の基準は最低限の基準を決める座標であり、それ以前に自分でいかに納得できる仕事をするか、充実している仕事ができるかという仕事をするのが私にとっては一番の評価基準だと思います。現時点でその基準の低い時点にいるのであれば、それをどう改善するかの対策を立てて常に充実できる仕事をしていくということでしょう。

ウェブディレクターの仕事の優先順位考

修行中ウェブディレクターのつぶやきです。

最近ウェブディレクターの仕事として大切な仕事の順位は
1. クライエントの市場の現状を理解し、将来の予測を持つこと
2. ウェブマーケティングのトレンドを理解すること
3. 1と2を満たすための個別の技術を理解して、ウェブツールにアプライすること

ではないかと感じています。1を明確に自分で持って、マーケティングを立案することで数字を出して計画ができ、マーケットをリードする可能性を高められます。もちろんバランスは必要で、2と3を知らなければ頭でっかちの役立たずになってしまいます。

私の性格としてなかなか最後の詰めがうまくないので、大枠を決めるという仕事も性に合っていると思います。

ウェブディレクターとディベロッパーの兼業は、ウェブ業界を上流のもっともクライエントに近いポジションと技術者の一番下流の立場から挟んで攻めることができるので、私の現状ではとても良い仕事ができるポシションだと思っています。

passive crime

月間ニュース情報誌のCOURRiER Japon５月号を読んでいて、北海道夕張の市長鈴木直道さんが自分の給与７０％カットの約２６万円／月で仕事をしているという記事を読みました。自分の評価で給与を決めているのだそうです。成果を出せばもっと給与をもらうということですね。反対に私の住んでいる宝塚市では給与をカットする案が否決されたというチラシを最近目にしました。宝塚市の広報によると、平の公務員でも１ヶ月の給与が課税前で５０万円ぐらいあるようです。

バブルの末期には政治家の賄賂で何億円もらったという記事が多くあったように思えます。数年前には秘書給与流用が何件か話題になりました。個人的にそれだけの仕事をしていれば政治家が何億もらおうが（稼ごうが）正当だと思います。仕事をして成果を出していなければもらわない。それだけの成果を出していないのに税金から給与をもらっているというのは、立派な犯罪ではないでしょうか？こういう言葉は存在しないかもしれないですが、"passive crime"といえると思います。ある意味意識的に犯罪を行っている犯罪者よりも、犯罪を行っている認識が意識の裏にありつつも目をつぶって見えない様に振る舞っているのは業が深い様に思います。”自分の小さな「箱」から脱出する方法”という書籍にも触れられていましたが、罪っていうのは根本的に自分に対して嘘をつくことから始まるのではないでしょうか？

売り手と買い手がの要望が”ぴったり合う”ためのマーケティング

事業者にとって、マーケティングは自社の商品を売り込む重要なビジネスの要素だと思います。しかし一歩下がってみると、必要としている人に必要としている情報が届き消費に結びつくというのが持続的なカスタマーリレーション構築の為には必須であるのかもしれません。自分が売るという立場にいなければ、客観的にどのようにすれば情報が一番良い形で交換されるのかという視点に立てるのですが、自分で売るという立場になると途端に盲目になってしまうという心理も存在します。この点でマーケターにとってはマーケティングを客観的に調査・選択して実行に移すのは禅問答的な行為に相当するのかも知れません。

Peter Morville著の「アンビエント・ファインダビリティ」はどんな情報でも見つけることができる状態になるという視点でこの本を書いています。これはどこにいても見られている可能性があるということも意味します。そうなることによってのセキュリティー保全の問題や倫理的な問題はひとまず置いておいての議論を展開します。

ウェブマーケティング関係者として、現実に役に立つ見解は、コンテンツ提供者や技術者はハイテクレイヤに気を取られがちだが、実際に情報のファインダビリティを決定するのはもっと原始的な人間の心理を理解するところにあるという点です。技術はその心理の法則に従って情報を見つけやすく導くための道具にすぎず、その存在さえ意識する必要の無い状態が良い。ITという概念より一歩人間に寄ったHCI(Human Computer Interaction)という概念から更にC(Computer)を除く方向性に導いていく必要がある。

新しい議論ではないですが、ウェブのIA(Information Architecture)という観点で言えば、例えば検索エンジンから特定のページに直接飛んでくる人たちがいます。この人たちはそこで目にした記事に興味、信頼性、などを感じればコトラーが「消費者の意思決定の流れ」という概念で説明している様に何かのサービスを必要とする際に記事を書いた人をサービス提供者として選択する可能性が高くなる。

むしろ面倒なのはトップページから入ってきた人で、このような人たちは「berrypicking」という情報を段階的に見つけていくプロセスのステップをより多く踏んでもらう必要がある。ここでは探している情報にたどり着くというよりもその人にぴったりの情報が見つかること、そしてその過程を気持ちよく体験できるという状態を提供することが重要になってきます。

このberrypickingをいかに”ぴったりな情報が見つかる”という状況に近づけるかという研究は多くの研究所や企業がしています。それらの技術を利用し、ハイブリッドでユーザに提供できるようにすればかなり面白いUX(User Experience)を提供することができるのではないかと考えます。Googleはできるだけ多くの人に人気のある記事、信頼のある記事にユーザがたどり着けることを目的として検索のアルゴリズムを組んでいるのが現状のように感じます。ソーシャルでは自分の知っている人の情報が一番重要。

記事の分類一つをとっても下のようにさまざまな分類の仕方があります。

taxonomy --> ロジックで分類

folks-onomy --> 記事に貼付けられたタグで分類。多くの人がタグをつけて一つの情報を整理することからfolks(人)が分類するという意味の名前がついたのでしょう。

decision tree --> 学習を付随させて、何パーセントの人が特定の情報に到達したか、緊急性はどの程度高いか、反対に見せる必要の無い情報はどれかなどのパラメータを任意に設定し関連性の高い情報のランク付けをする

ハイブリッド型の検索実装方法として、例えば

1. 最初にカテゴリーに分けられた”パソコン”などの項目をクリック
2. そこで更にキーワードで絞り込む
3. 表示された記事をクリックしたがまだ情報が足りないという気がするため
4. 関連性のある記事がいくつか並んで表示されている中から”ピンとくる”記事のタイトルをクリック

というような流れで特定のユーザにぴったりの情報がマッチするという過程が生じるのということも可能です。実際多くのサイトでハイブリッド型の情報サーチは実装されていますね。例えばアマゾンであれば”キーワード検索”、”モデルで絞り込み”、”価格で絞り込み”、更にそれぞれの商品ページにはおすすめの商品が表示されるなど事例は豊富ですね。

これらの知識は一歩下がって選択・決定する価値基準を与えてくれるのに役に立ちますが、現実のサイトに実装して運用、改善のサイクルに放り込む過程は一つの試練ですね…。

コピュータ、AIなどの進化に付随するさまざまな憶測や悲観、批難などもあります。例としては携帯に電場番号を保存できるようになったとたん以前は何百件の電話番号を覚えていられた人がとたんに５件の電話番号も覚えていられなくなったという経験談もあります。インターネットに取られる時間が多くなり、直接のコミュニケーションが少なくなったなど。私は技術に溺れるのも利用するのも所詮いつの時代でも個人の意思に委ねられているという立場を取ります。

本のシェアします

書籍は多くの場合一度読んで内容を理解すれば必要がなくなってしまうにも関わらず、一般の図書館で見つからない専門書関連は購入するしか方法が無いのがもどかしく思います。書籍を交換したい人たちのネットワーク BookMooch というサイトを知り合いに教えてもらいました。

書籍は買う方だけではなく、買ったあとも家に置いておいても宝の持ち腐れだし、反対に場所とるので邪魔になるぐらいです。フリーランスとして仕事をしている人たちは同様のことを感じている人が多いのではないかと思います。個人的には引っ越しをする頻度も高いので書籍も含めた所持品は無に等しい状態がベストだと思っています。

この BookMooch というサイトはイギリス生まれでカリフォルニアに１年の半分は住んでいるという制作者（情報が正しくなければ済みません）が運営しています。アメリカ、イギリス、フランスにユーザが多い様ですが、日本でも現時点で約1,700冊がリストされています。ただ日本国内でこのサービスを利用している人たちは日本語を母語としない人たちが多い様です。もしかするとこのようなおおっぴらな行動様式は特に英語圏の人たちの特徴かもしれません。英語が現時点である意味ポピュラリティーを浴びているということも原因でしょう。サイトはもうちょっと検索機能が強化されれば使いやすくなるのにという部分が残念ですが。

私も早速アジャイルやRails関連の書籍をリストしてみました。--> http://bookmooch.com/m/inventory/taro 興味がある本が見つかれば着払いで送ります。コンタクトください。

今後、日本国内でも日本に国籍のある人・無い人関わらずごちゃ混ぜになって書籍を交換する様になれば良いなあと思います。他の中古品、例えば家具や自転車、その他なんでももっと交換して利用する文化が流行すれば良いなと個人的に思っています。

Herokuデプロイ環境基礎勉強

HerokuでRailsアプリケーションを走らせる際の基本的な技術について調べて見ました。ざくっと言えばHerokuはサーバ管理などの知識が（ほぼ）無くても、ウェブアプリケーションを作ったから公開したいと思えば簡単にできるプラットフォームですよね。背景技術に詳しくなれば高度なカスタマイズも可能なのでしょう。

Stackのレベルから調べようと思い、HerokuのCeladon Cedarの項目を読み始めたのですが、出だしの文章が

Celedon Cedar is Heroku’s most recent runtime stack and is a flexible, polyglot environment with robust introspection and erosion-resistance capabilities. [cont.]

何のことやら…。Celadon Stackとか、データベースのプランがRoninとか、名前からサービスの内容が全然連想できないところも絶望的ですね…。気を取り直して地道に一語ずつ拾っていきます。

(Runtime) Stackはアプリケーションをアップロードすると、多くの言語を勝手に認識してデプロイに必要な環境（WEBRickやThinのようなHTTPリクエストをさばくdaemonとMRIのようなインタープリターを乗っけて動かす環境）を構築してくれる基礎のようです。私はMRI1.9.2を使用しているCeladon Cedar stackを作成し、ThinにHTTPリクエストをさばいてもらい、Railsアプリケーションを動かしています。

もう一つ分かりにくかったのがDynoという概念です。Process Modelという概念によりプロセス単位でスケーリングができる様に設計されているようで、その１プロセスを1 Dynoと呼んでいるようです。Web Dynoを増やせば同時にさばけるリクエストの量が増え、リクエストをさばくことにリソースが制限されるサイト（静的コンテンツをキャッシュに保存しておいて提供するサービスがメインのサイトなど）に関してはWeb Dynoの増減がスケーリングで考える重要な項目になってくるのでしょう。一方でWorker Dynoはcpuを消費する例えばオンラインシューティングゲームなどのサーバ運営でスケーリングを考える必要がある項目でしょう。いずれのDynoも自分の経験としてまだどれぐらいのアクセスで1プロセスを増やさなければいけないという感覚が掴めていないのは残念ですが…。ちなみにHerokuのプロセススケーリングを自動で管理してくれるHero Scalingという外部サービスもあるようです。

今回はHerokuデプロイ環境の本当に初歩の部分にしかたどり着きませんでしたが、今まであまり関与してこなかったインフラ系の知識もアプリケーションの開発や運営手法と共に車の両輪のように学んでいきたいと思います。ウェブマーケティングの知識を得る必要もありますし、課題は多いですね…。