http://chroju.github.ioこの広告は、90日以上更新していないブログに表示しています。Capistrano昨年末に自身初のRailsアプリを見切り発車という名でローンチしましたが、その際デプロイで1か月以上もハマってましたので、ハマリポイントをピックアップしてまとめておきます。cloneでレポジトリをダウンロードしてくる過程があるのだが、ここではもちろん、GitHub(他のサービス使ってる場合は他の)にアクセスするためのssh秘密鍵が必要になる。forwardingを使えるようにするための設定箇所が存在するので、リモートに鍵をわざわざ転送しなくても、ローカルの鍵が使える。設定箇所はdeploy/(test|staging|production).rbの中で、サーバー設定を書くときに以下のようにforward_agentをtrueで宣言すればいい。/var/wwwがnginxの見に行くルートディレクトリになっていて、Railsのアプリは/var/www/railsで展開しているというように、サブディレクトリを使う場合はRails側に環境変数RAILS_RELATIVE_URL_ROOTの設定が必要になる。Railsがlink_toなどを展開してパスを埋め込むときは、このroot設定が元になるので、サブディレクトリを使っていることを環境変数上で明記してやらなければ、本来http://example.com/rails/hogeへのリンクを展開してほしいはずが、http://example.com/hogeが展開される、といったことになってしまう。設定箇所としてはconfig.ruになる。Rails.applicationendはっきり言ってconfig.ruが何者なのかよくわかってはいないのだが、Rackサーバーを起動するrackupコマンドに起動オプションを渡したりするもの、らしい。そのことについてはconfig.ruの先頭行にコメントでも入っているのでなんとなくわかると思う。Rackが理解できてないので結局のところわからない。コマンドは意味から考えれば、Railsを起動するときにパスのマッピングとしてRAILS_RELATIVE_URL_ROOTを渡してやっているように見える。この書き方だと環境変数の宣言をconfig.ruの中で行った上で、その環境変数の存在をifで確認するというちょっとマヌケなロジックになってしまっているので、おそらくは環境変数を別のところで宣言するのがベターなのだと思う。unicorn)に対しても設定が必要だが、ここでは割愛。nginxのlocationディレクティブを使う、とだけ覚えておけばなんとかなるはず。Diaryassetsに対するルーティング設定assets:precompileを使ってあらかじめassetsフォルダ内にcssとjsを展開していたのだが、ブラウザ経由でいざアプリにアクセスすると、CSSもJavaScriptも適用されていない(assets配下が読み込めていない)という事象が発生した。原因はルーティングが正しくなかったから。前述の通りExhiBiでは/var/www/railsにアプリを展開していたのだが、さらに細かく見るとrailsフォルダの中にはreleases、current、sharedという主に3種類のフォルダが配置される。cloneの対象フォルダで、ソースコードをCapistranoで宣言した数だけバージョン管理している。sharedはbundleやlogといった、リリースバージョンに左右されず不変のファイルを格納する場所で、Capistranoで言えばlinked_dirsにあたる。この2つのフォルダをcurrent配下にシンボリックリンクすることにより、currentが実際のアプリ配置場所として機能する。従ってnginxのlocationディレクティブはこんな感じになる。/var/www/rails/current;}ここでassetsへのルーティングを考えてみると、assetsに対するパスはhttp://example.com/rails/assets/hogehogeになるため、/var/www/rails/current/assetsを見に行くことになる。実際にはassetsはshared/public/assetsであり、シンボリックリンクはcurrent/public/assetsに貼られている。そのため先のlocatonだけではassetsに到達することはできないため、assets用のlocationディレクトリが別途必要になる。QiitaSECRET_KEY_BASEの環境変数設定ブラウザ経由でアプリにアクセスしたら、404ではないのだが画面が真っ白になってしまう事象。ぐぐってみるとドンピシャすぎる記事があって大変助かった。EasyRambleSECRET_KEY_BASEという環境変数を設定してやらねばならんらしい。環境変数の設定なので方法は下記のURLのようにいくつかあるみたいだが、自分は取りあえずChefレシピの中で、.bash_profileへ環境変数設定をいれこむことにした。これも何かしらベストプラクティスがありそうな気がする。'pg'が入らない入らない。なんか知らんが入らない。ググるとどうも入りづらいGemの筆頭である模様。探って、therubyracerを先に入れるべきだと聴いてやってみたけど結局入らない。bundling.と言われてしまう。installを手動実行してみるとなぜか入る。これだけは本当にわからん。その後はtiltが入らないとか言われたりもした。ソースをrubygems.orgから変えたりしてなんとか入ったのだが、ちょっと腑に落ちない感。momentposgresqlのユーザー管理SQLに関する基礎知識のなさを猛省した。わかってなかったのこんなとこ。TECHSCORE(テックスコア)Rails、Capistranoのいずれも抽象度の高い技術で、これは何度かブログに書いてきてるけど、その内実をきちんと押さえてないとエラーが起きた場合に結構辛いことになる。READMEを読むこと、公式のWikiなどがあるならそっちも目を通すこと、エラーが起きたらログを見ること、あるいは前もってログを吐く設定にしておくこと。このあたりは改めて徹底したいところ。あとここからは余談だが、Railsのデプロイ先としてherokuが好まれるのは、ある程度「間違いのない選択肢」ということなのだろうなと想像している。ここで自分がつまずいたサブディレクトリでのアプリ展開や、postgresqlのコンフィグなどは、herokuであれば必要がなくなる。用意されている高速道路を全力で走ってみて、それが成功してから自分好みに変えていく方が近道なのかもしれない。なんとかしてposgresqlを使おうとこだわったり、サブディレクトリでの運用をさせたり、最初からいろいろ欲張りすぎた点も反省。22:22Railsのデプロイでハマった点まとめTweet広告を非表示にするもっと読むコメントを書く2014-12-29美術展検索サービスExhiBiを見切り発車しましたExhiBi初めてウェブサービスをローンチしました。ネタとしてはすでにゴマンとある美術展の検索サービスです。既存のものがあんまりしっくりこなかったので、自分向けに対象を絞って、掲載情報も絞ったものを作ろうかと。現時点だと絞りすぎてまだ出来てなくてMOTとMOMATしか範囲に入ってないッス。タイトル通り超見切り発車。ExhiBiと書いてエキシビと読みます。技術的な面では自分が「コードを書けないエンジニア(GUIによる設定ばかりに従事しているインフラエンジニア)」なので、何かしら書けるようになりたいよねということで、汎用性も高そうで文法的にもしっくりきたRubyを選びました(細々した理由は他にもいろいろとありますが......)。フレームワークには当然のごとくRails、中身のデータはMechanizeで美術館サイトから取ってきてます。Codeを意識したかったので、ChefとCapistranoを軸に構築してます。若干手作業が残ってしまったのが気掛かりなので、後々なんとかしたいところ。Railsのデプロイ、めっちゃめちゃハマりポイント多かったんですがなんなんですかね......。開発自体は半月で終わったけどデプロイで1か月以上苦しんでました。自分が単に知見がないってだけの話なのか、元々そういうものなのか。オライリーもRailsのデプロイだけで1冊出してるぐらいなので、結構難しいものなのやも。今後やりたいことは取りあえずこんな感じ。気になる美術館を同上レスポンシブ、とかデザイン面をもうちょっとコードきたねーので整えるはてなブログのembed記法に対応させる(冒頭のリンクだとなんかダサい)コードは一応GitHubに上げてますが、場当たり的に直しちゃったところもあるんで汚いです。いうか仕事でコード書いたことないからもう少し作法とか身につけたい。なんとか年内にあげようと思ってたんで、間に合ってホッとしました。技術的な話はおいおい少しずつブログにまとめていきます。9,418Amazon.co.jpで詳細を見る去年の末ぐらいに話題になってた本だと思うけど、読み終えた。自分はネットワークスペシャリストを持っているんだけど、IPAの資格って基礎を満遍なくさらっておくには良いんだが、じゃあその知識の中で今現場で必要なのどれよ?ってのがなかなかわかりにくい面がある。この本はその「現場で実際どうネットワークは組まれるのか?」という部分に大きく焦点が当たっていて、知識を実践的なものに洗練できる。L3をコアスイッチにして構成していくのが主流ですみたいな話から、ケーブルにタグ付けてこういう情報書いておきましょうなんていう細かいことまで載っていて隙がない。いうことができる/できないという知識があったところで、じゃあそれがネットワークを組む上でどう活きるかというのはまた別の話であって、そこを弁えてないと車輪の再発明に手を煩わせてしまったり、組んだ構成が主流から外れてたりということはままある。自分がまさにそういう状態で、ベストプラクティスをきちんと押さえていないことがずっと気がかりだったので、今ネットワークを触る上でベターなやり方、注意点を体系的に学べたのはとても良かった。知識レベルとしては応用情報技術者があれば読めるレベルだと思う。1〜2年目ぐらいでネットワークに携わり始めたぐらいの社員が読むには本当に優れた1冊です。情報/タスク管理インプットに対してアウトプットの量が少ないなと前から思っている。ブログを書いてるとアウトプットの履歴が残るから「アウトプットしてない」時期が明確にわかり、それを見て不安になったりもするんだけど、結局書けてない、ということが続く。何かコーディングするときや構築するとき、わからないことがあるとついついググって探して実装して、そのままにしてしまうことが多いんだけど、これだと一過性で終わってしまって、結局記憶に残らず終わったりする。はてブしたりEvernoteにクリッピングしたり、ぐらいはするときもあるのだが、これはこれでクリップしたまま記憶の底に埋もれていくので、やっぱり身になった気がしない。知識の定着を図るなら、何度も繰り返し試してみるか、インプットした内容を頭の中で咀嚼して、その経緯を自分なりにアウトプットし直すのが一番いい。なんで書けないのか?というと怠惰という理由が最も強いように思う。壁にぶつかったときは山のようにググって比較検討して答えを見つけようとしてしまうから、結局どのページを見て正答に至ったのかが曖昧になったりしやすい。公式ドキュメントにあたるだとか、試行錯誤した結果でさえ一つ一つ丁寧にログを残すだとか、そういうことをできていない。ちなみにメモツールとしてはアナログだとモレスキンのラージ、デジタルだとVimプラギンのQfixHowmを主に使っている。QfixHowmを使っているのは正確にはプライベーとのPC上だけで、要はDropboxにプレーンテキストでメモを書き溜めている形になる。Calendarに全部移行していたので、もう手帳を持つ意味もないなと思い、自由度の高いモレスキンに変えた。職場の関係でDropboxは使えないし、ノートPCを叩きながら打ち合わせに臨むのも好ましいとされていないので、アナログのメモはどうしても捨てられずにいる。miniにタッチペンとか使うよりも広めのノートの方が脳と手が直結しやすくて楽。基本的にはこれらに「なんでも書く」方針でいるのだが、散漫な思いつきなどは書けていても、本を読んだり勉強しながら書く習慣がない。tmux開いてコーディングして、ウィンドウを切り替えてメモしてという手順を踏めばいいはずなんだけど、ついつい怠ってしまう。プログラマーの三大美徳に「怠惰」が含まれてはいるが、究極の怠惰は生産性を持たないものだと思う。書くためにどうしたらいいのか?という問いに対する答えは自分でもまだ見出だせていない。いうのはもう性格レベルの問題なので、「意識する」とかそういう類の対策じゃなんの意味もなくて、もっと根本的にメモせざるを得ない状況を生み出すしかないのだと思う。メモの効用をより強く自覚すること。怠惰とはいえ、本当に必要だと思っていることはそれなりにこなせてはいるので、メモを書いてないことで痛い目見るような経験がもっと増えれば変わるような気はする。2014に行ってきたイベントイベント終了から1週間後にレポートとか遅すぎますね。OpenStackの話→Matz氏→Chefの中の人という大変ミーハーなタイムテーブルで回ったけど、著名なハッカーの話を聞く機会というのは何度か設けておくべきなんだろうと思う。当然ながらウェブや雑誌で何度も著名な人の話は読んでいるわけだけど、実際目の前で話してもらうと記憶への残り方とか、影響の受け方とかやっぱし違ってくる。Matz氏の話を聞いていて思ったのが、エンジニアとして哲学というか思想というか、そういうのはきちんと持っておきたいなということ。エンジニアというのは知的生産、クリエイティブワーカーだという人もいるが、意識によっては単なる流れ作業の駒になりかねない。実際、自分の今の仕事というのはそちらに近くて、顧客からの要件をいかに盛り込むか、いかに期日までにリリースして検収をもらうか、というところにばかり目がいってしまっていて、全体のデザインが出来ていないことはままある。短期的に売りを上げるだけであれば別にそれでいいのだが、思想のないシステムは運用上のトラブルが多いだとか、更改や拡張に対する思慮に欠けているだとか、長期的には利を失うことにつながりやすい。キャリアデザインとしても、思想がないエンジニアはブレる。いうか、単に売り上げて金回すサラリーマンエンジニアになりたいのか、それともいわゆるハッカーとしてやっていきたいかの境界線の一つがそこなんじゃないかなと。どちらが良し悪しではないし、どちらでも人生で「やっていく」上では困りはしないとは思うのだが、どちらが自分にとって楽しいかが問題だ。自分は結構収入面って後回しに考えていて、自分が思うような価値を生み出せる人間になれればいいと思うし、その対価として金が得られればそれでいいのかなと思う。リクルーティングとしてのイベントいろいろと縁があって、ビジネス的なつながりがない企業の中では楽天がおそらく一番多く訪問してるんだけど、今回はだいぶ中の方まで入り込めて、ちょっとだけ実態が理解できたように思う。噂の楽天ランチは大変楽しみにしてたのだが、思ってたより薄めの味付けで社員の健康を考えている会社って素晴らしいなぁと感心してしまった。その後、カフェテリアで開かれる午後のセッションに行ったら無料でピザやらポテトやら唐揚げやらコーラやら配られてたんで、「あかん、これ罠や」と思いました。あと周知の通り社内は英語公用語化していて、イベント自体も英語が基本なんだけど、実態としては会場内の案内は日本語遣うスタッフもいたし、本当に英語しか喋らない外人スタッフもいるし、日本語喋る外人スタッフもいるしでわりと脳味噌混乱した。参加者側も外国籍の人が半分ぐらいいたんじゃないかという感じ。いうあたり、単純にエンジニアイベントというよりは、楽天という会社の在り方をアピールする機会として本当にうまく活かしていたなと思う。Partyも開かれているのはちょっとびっくりしたけど。20Amazon.co.jpで詳細を見る何ヶ月か前にKindleでアスキー本のセールをやっていたことがあって、そのときに買ったのをやっと読み終えた。技術書を電子書籍で読むというのは、感覚の問題なんだけどどうも身が入らない。ドッグイヤー付けたりとか書き込んでみたりとか出来なかったり、あるいは満員電車の中とかでも手軽に読めすぎてしまって、腰を据えて勉強する感覚がなくなるからなのかなぁという気がしている。miniを買った模様。他にも理由はあったけど。自分はVimを使い始めて1年ちょいというところで、これまでVim本をきちんと読んだことはなかったのだが、読んでよかったと思う。Vimの情報はネットにありふれすぎていて、素のVimから触り始める人ってあんまりいないような気がする。自分も最初からKaoriya版を使っていたし、使い始めてまもなくGitHubやQiitaから他人のvimrcを拝借してきて、NeoBundleでプラギン入れて使っていた。プラギンまわりが楽しすぎて、ほうほうVimはこんなことができるのかー!とwktkしながら1か月ぐらいはvimrc触りまくってたように思う。自分のGitHub見るとまーよくわかる。この本にも書いてある通り、まずは素の状態で試してみるべきなのだ、本来。Vimは最初からできることが豊富にある。テキストを扱う上で必要な操作がいくらでも揃っているので、まずはそれらを味わってみて、足りなければvimrcで味付けしていけばいい。ないとVimの設計思想というか、Vimによってテキストをどう扱うべきなのかという原則論が見えてこない。本書はプラギンの話は皆無で、Vimが最初から備えている機能を中心に解説されている。.を始めとした繰り返し操作を多用する考え方だとか、テキスト対Vimというありがちな考え方だけではなく、ファイル対Vimという考え方もしなくてはならないとか、学べることは本当に多かった。あまりに分量が多いので一気にすべてのことを実践できるわけではないが、これはと思ったとこから取り入れていきたい。Vimはツールではなくて思想なのだ。親指シフトやHHKBなんかと同じように、最速でテキストを編集するための思想。ここでいう「Vim」には「Emacs」も当てはまってくるのだろうけど。あと正規表現ちゃんと覚えなあかんなと思った。後半の検索、置換のあたりは当然ながら正規表現を使える前提の話が多くて、きちんと使えてない自分には少ししんどかった。Linuxで使っているデスクトップマネージャ、awesomeのテーマに若干手を入れてみたので備忘録。日本語ドキュメントないので、このあたりのカスタマイズしんどかったです。テーマファイルの構成awesomeの設定はいくつかのLuaファイルを使って書き換えていく。基本的には全体設定を司る~/.config/awesome/rc.luaと、外観やテーマを司るライブラリである、Beautifulの設定ファイル~/.config/awesome/themes/default/theme.luaの2つを覚えておけばいいのかなと。いずれも初期状態では配置されてないので、デフォルトファイルをコピーしてきて使う。~/.config/awesome/themes/defaultBeautifulについてはrc.luaの中で設定ファイルのパスが指定できるので、defaultという名前が嫌だったら任意で変えてもOK。あとは正直awesomeのWiki見るのが手っ取り早いとは思うのだが、設定したところだけ書いておく。ちなみに前回記事で書いたが、awesomeのデフォルトターミナルの設定もrc.luaを使うので、外観変える必要なくてもrc.luaだけは確実に要ると思う。タグリストの書き換えawesomeでは仮想デスクトップを"tag"と呼んで扱っていて、デフォルトの状態だと左上に1から8まで(だったかな?)の数字がタグの番号として並んでいる。わかりやすいものではないし、そんなに多くタグも使わないので書き換える。layouts[1])endあとウィンドウを開いているタグは小さな正方形が表示されたりしていて鬱陶しかったのと、あまり見栄えも良くなかったので、正方形を表示されないようにした上で、フォーカスしているタグは文字色を変えることにした。これはbeautifulの方で設定する。"/usr/share/awesome/themes/default/taglist/squarew.png"1行目がフォーカスされているときのfg、フォアグラウンドカラーの設定。2、3行目はデフォルトで入ってる設定だったのでコメントアウトしておいた。画面上の情報表示はウィジェットとして扱う。ウィジェットを管理するライブラリはいくつかあるみたいなんだが、取っつきやすそうなので自分はviciousをrc.luaの中でrequireして使っている。require("vicious")設定の順序としては、awesomeがもともと備えているウィジェット生成用のAPIであるwiboxを使ってウィジェットのの原型をセットし、これにviciousを使って表示させたい情報をセットする。ここではバッテリー状態と音量、Wi-Fiの状態を表示させる。どんな情報を表示させられるのか、詳細はここ。"wlp1s0")ウィジェットを作ったら、画面上のレイアウトにウィジェットをセットする。endright_layout:add(soundwidget)right_layout:add(battxtwidget)right_layout:add(wifiwidget)right_layout:add(mytextclock)right_layout:add(mylayoutbox[s])自分がした設定はこの程度。10"の設定でフォントサイズを少し大きくしたぐらいだが、beautifulの設定ファイルを見ればわかる通り、かなり細かく色やら何やら設定ができる。このへんに凝り始めるとキリがないので自分はやめることにしたが、好きな人はやってみたらいいんじゃないですかね。1つ、GitHubですげーカッコイイテーマ配ってるの見つけたんで貼っときます。Samuraizuとか思い出すなー。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。