タグ

ブックマーク / higelog.brassworks.jp (19)

  • VagrantとChefでチームの開発環境を共通化する - ひげろぐ

    インフラ構築のテストに遅まきながらVagrantを使おうと色々調べていたが、チーム開発の開発環境を共通化したい、という声がメンバーがから上がったのでそっちの方もVagrantでやることにした。 Vagrantで仮想マシンを作ってChefで環境構築できるようにしたものをメンバーに配布する流れ。 概要 VagrantはVirtualBoxのような仮想マシンのフロントエンドツールでAmazon EC2やVM Wareに対しても使うことができる。 コマンド一発で仮想マシンを立ち上げたり落としたりできて便利。エディタで設定ファイルを編集して仮想マシンの設定を変更することも簡単。プラグインでの機能拡張もでき、仮想マシンを一時的にSandbox化できるSaharaなどが有名。 詳しくは以下。 Vagrantで簡単仮想マシン構築 | Ryuzee.com Vagrant – naoyaのはてなダイアリー

  • Passengerがメモリを食いすぎるとき - ひげろぐ

    Passengerを動かしているサーバのメモリ使用量が突然跳ね上がってスワップをガリガリ発生させることしばしばだったので最近いろいろ調整していた。 結論としては二つ原因があった。 Railsインスタンスプロセスの立ち上がりすぎ PassengerMaxPoolSizeを適切に設定してないとそうなることがある。 PassengerMaxPoolSizeのデフォルトは6なのでRailsインスタンスが一個につき400MBのメモリをっていたら最大で2.4GBのメモリをうことになる。 というわけでメモリが2GBのサーバでも撃沈する。(まあ400MB消費すること自体がおかしいけど) インスタンスひとつあたりのメモリ使用量を把握するにはしばらく動かしてみるしかないと思うので(何か方法あるかな?)最初は小さめに設定しておくのが無難かもしれない。 この値が1とか2くらいでも小さなサービスでは全く問題ない

  • RubyMotionはiOS SDKに疎い人にもオススメできる - ひげろぐ

    iOSで作りたいモノが特にないのでこの頃あんまりアクティブに触ってはいないけど、一方で所感が確かな物になってきたので書いておきたい。 RubyMotionがリリースされたばかりの頃はiOS SDKの知識が必要なので敷居が高いのではと書いたが、それから三ヶ月弱立った現在、iOS SDKに疎くても気にせず開発できる環境が整ってきた。またREPLの存在によりiOS SDKを学ぶにも役に立つものだと思うようになった。 加えてどれほどの物が作れるのか、ということとサポートの話など。 Rubyらしく書く BubbleWrapのようなRubyらしく書いていけるライブラリが順調に育っていて当初よりかなり良い感じになっている。 iOS SDKの知識がなくてもかなりの所までいけるようになっているんじゃないだろうか。 他にもDSL的なライブラリがいろいろできて盛り上がっているので、今後も「Rubyらしく」という

  • RailsアプリでActiveRecordを使ったバッチ処理 その2 - ひげろぐ

    script/runnerを使うといいようだ。 これは引数の文字列をRubyスクリプトとして解釈し、Rails環境で実行するというもの。 script/runnerによって ruby script/runner 'p Onsen.count' といった具合にコマンドラインからモデルを使った処理を実行できる。 コントローラは使えません。(でした) 対象にする環境は-eオプションを使ってdevelopment,production,testをそれぞれ指定できる。 何も指定しない場合のデフォルトはdevelopment。 ゆえにproduction環境で実行したければ以下のごとし。 ruby script/runner -e production 'p Onsen.count' ちなみに多少複雑なバッチ処理は当然ファイルに書いたスクリプトから読ませたい。 しかしそのために普通にパイプとか使っても

  • RubyMotion Weekだった今週 - ひげろぐ

    かなりの盛り上がりでGitHubには雨後の筍のように新しいプロジェクトが次々できている有様。 個人的にも昔Objective-Cで書いたものをRubyで書き直してみたりしていてRubyMotion成分濃い目のエキサイトした週だった。 正直勢いがありすぎて自分では追い切れてないが、公式ブログにリリース後一週間の熱狂が綴られていたので抄訳してみる。 RubyMotion’s Blog — What a week! コミュニティ 今日までにユーザーによる約55のRubyMotion関連リポジトリがGitHubにできている GLKit/OpenGL, Facebook, Parse, cocos2d等の特殊なフィーチャーやフレームワークのサンプルデモ CoreDataやUIKit等の抽象化 Redcar、TextMate、Vimのコード補完を含むRubyMotionサポート RailsFactor

  • Titanium MobileとRubyMotionの比較 - ひげろぐ

    双方とも脱Objective-Cを実現してくれるプロダクトだけど性格はけっこう違う。 共通で興味を持っている人が多そうなので思うところをとりとめもなく書いてみる。 取っつきやすさ iOS SDK開発未経験者がとっつきやすいのはTitanium。おそらくRuby経験者でも。 逆にiOS SDK経験者ならばRubyMotionの方が入って行きやすいかもしれない。 RubyMotionはiOS SDKのAPIをタイトになぞっているためにiOS SDKのAPIに関する知識が必要だが、iOS SDKのAPIには直感的じゃない部分が多々あって、それに馴染むまでけっこう時間がかかる。その学習コストがけっこう高い。 TitaniumのAPIはTitanium独自のものだが整理されていて扱いやすい。学習コストは皆無ではないがiOS SDKに比べればずっと楽。 またObjective-Cよりマシとは言えRub

  • RubyMotionでCocoaPodsを使う - ひげろぐ

    CocoaPodsはRubyで言うとBundlerみたいなもの。 Objective-Cのプロジェクトにおいてライブラリの依存性を管理して使いやすくしてくれる。 podとして提供されているライブラリの一覧はここにまとまっている。 RubyMotionでもこのCocoaPodsを利用できる。 以下だいたい公式のドキュメント通り。 CocoaPodsのインストール まずはCocoaPodsを入れてセットアップする。sudoはRVMを使っているなら不要。 $ [sudo] gem install cocoapods $ pod setup motion-cocoapodsのインストール 次にRubyMotionからCocoaPodsを使うためのmotion-cocoapodsを入れる。 $ [sudo] gem install motion-cocoapods Rakefileの修正 RubyM

  • mod_proxy_balancerで503がくせになった時のメモ - ひげろぐ

    またあるかもしれないのでメモっとく。 エラーの始まり 先日DBの障害でバックエンドにDB接続待ちのプロセスがあふれかえったのを機に、その問題が解消した後もサイトが503エラーをたまに吐くようになった。 mod_proxy_balancerを利用したロードバランサーには以下のようなエラーログ。 [Thu Dec 15 12:00:00 2010] [error] (113)No route to host: proxy: HTTP: attempt to connect to 192.168.1.101:80 (192.168.1.101:80) failed [Thu Dec 15 12:00:00 2010] [error] ap_proxy_connect_backend disabling worker for (192.168.1.101) しかしロードバランサー側にもバックエンド

  • Rails標準のテストとRSpecのテストの種類の対応 - ひげろぐ

    RSpecへ移行した観点からの所見 狭い見識からちょっとした雑感をば。 コントローラのテストが書きやすくなった Railsの機能テスト(Functional Test)ではコントローラとビューのテストをいっしょくたに扱っていたが、RSpecでは別々になっている。 そのためコントローラのテストが書きやすい。 データベースからの値の取得やセッションの状態の確認、どのテンプレートをレンダリングしているか、httpのレスポンスの結果は何か、などコントローラの仕事だけにフォーカスしてテスト(「Example」と呼ぶべきなんだろうけどまだなじみがないので「テスト」で)が書けるので、ビューテンプレート側での変更などを気にする必要がなくなった。 デザイン変更で機能テスト失敗するようになりましたとか言う凹む状況から解放された。 ビューのテストはいらない子になった 同じようにビューのテストでもビューテンプレー

  • マイグレーション関連のRakeタスクの再確認 - ひげろぐ

    Rails 2.1になってマイグレーション周りで追加されたタスクや覚えておくべきタスクについての確認。 追加された db:migrate:up db:migrate:down 覚えておいた方がよくなった db:rollback db:migrate:redo db:abort_if_pending_migrations 追加された – 各マイグレーションのupとdownを任意に実行できるように 2.1からRakeタスクに「db:migrate:up」と「db:migrate:down」が追加された。 これにより各マイグレーションのupとdownが好きなタイミングで任意に実行できるようになった。 それぞれupとdownを実行したいVERSIONを指定して実行する。14桁。めんどくさくてもちゃんと指定する。指定しなくてはならない。 $ rake db:migrate:up VERSION=20

  • Profile - ひげろぐ

    開発者としての強み フルスタック。インフラ構築からサーバーサイド、フロントエンドまでウェブ開発のいずれの領域でもそこそこのパフォーマンス インフラ構築の自動化(IaC)やテスト自動化による開発の効率化が好き 未経験の技術でもプロジェクト期間が3ヶ月以上あれば順応できるキャッチアップ力 スキル WordPress AWS Rails CI/CD TDD Infrastructure as Code 等々 スキルの棚卸も参照。 直近のお仕事 投票システム(React.js, API Gateway, Lambda, DynamoDB) 出版系ウェブサイト(S3, CloudFront) 医療系情報サイト(WordPress, EC2, Aurora, CloudFront) 会員制有料サイト(WordPress, Cloudways, VULTUR, Stripe) 出版系オウンドメディア(W

  • 素でRSpecを使うためのRakefile - ひげろぐ

    書き捨てってわけでもないけど、フレームワーク使うほどのものでもない。 ってかんじものを作るときに作ったもの。 というかGitHubのどっかからぱくってきたものですが。 # -*- encoding: utf-8 -*- require 'rubygems' require 'rake' $:.unshift File.join(File.dirname(__FILE__), "lib") require 'rspec/core' require 'rspec/core/rake_task' task :default => :spec desc "Run all specs in spec directory" RSpec::Core::RakeTask.new(:spec) ディレクトリ構成は lib spec Rakefile というものをを想定。 ちなみにGuard::RSpec使う

  • Guard::Bundlerでbundle installの自動化 - ひげろぐ

    最近Guardの中でGuard::RSpecと並んで必ずと言っていいほど使っているのがGuard::Bundler。 これを使うとGemfileを更新した際に自動でbundle installが実行されるようになりうれしい。 guard/guard-bundler – GitHub bundle installを忘れて首をかしげるといった地味にあるなるな状況とおさらばできて、けっこうな時間節約になる。 え?全然あるあるじゃない? まあそういう人にとってもbundle installとタイプする時間が節約できるのはいいことじゃないかな。 インストール Gemfileに以下を追記してbundle install。 gem 'guard-bundler' これが手で打つ最後のbundle installとなる。 Guardfileの作成 以下のコマンドを実行すると bundle exec gua

  • Rails3.1でAjaxを使う - ひげろぐ

    よく理解できていなかったのでチュートリアル的に整理した。 まずはチュートリアル用のアプリを新規作成して、コントローラーを一つ作る。 rails new ajax_tutorial cd ajax_tutorial rails g controller sandbox index update_time Ajaxなフォームやリンクを作成する form_forやlink_toといったヘルパーのオプションに:remote => trueを加えるとボタンを押した時やリンクをクリックした時のリクエストが非同期リクエストになる。 app/views/sandbox/index.html.erb <h1>Sandbox#index</h1> <%= link_to('update time', {:action => 'update_time'}, :id => 'update-time-link',

  • GuardでTitanium+CoffeeScriptの開発を快適に - ひげろぐ

    久々にTitaniumを触るにあたってCoffeeScriptのコンパイルをGuardにまかせることにしてみたメモ。 Guardはファイルの変更を監視して、変更があったタイミングで何らかの処理を実行できるツール。 これを利用するとCoffeeScriptを書いたそばから自動的にJavaScriptに変換するなんてことも簡単にできるわけで。 そしてそのものずばりのことを実現するGuard::CoffeeScriptなんてものがあったりします。 Guard::CoffeeScriptの導入 gem install guard-coffeescript これでGuard体も入る。あ、要Rubyです。 追記 ファイルシステム監視のために以下のGemも必要だった。 gem install rb-fsevent 上記はMacの場合でLinuxWindowsの場合は違うGemになるので詳しくはGua

  • nginx+UnicornでRailsのページキャッシュを使おうとしてはまった話 - ひげろぐ

    ここやここを参考に設定してみたが、nginx+Unicornの組み合わせでページキャッシュが効かなかったので、ちょっと試行錯誤。 最終的には以下を参考にしてなんとかなった。 RubyonRailsMongrel 原因 nginxがキャッシュファイルを見つけてくれなかった 状況を調べてみるとキャッシュファイル自体は作られている。 しかしRailsがキャッシュファイルを作るときにパス名に「index.html」か「.html」を付加したものをファイル名とするが、nginxはこの事情を知らないので、キャッシュファイルを見つけられなかった。 なので都度Unicornの方へリクエストを振っていた。 一方Unicornは静的ファイルへのアクセスをnginxに一任していた Rails3からはProduction環境ではデフォルトで静的ファイルへのアクセスを受け付けていない。 以下デフォルトのconfig

  • Rails3でパンくずリスト - ひげろぐ

    今まで不細工な自前実装をしていたけど、シンプルでお手頃なものがあった。 zachinglis/crummy – GitHub 導入 Gemfileに以下の行を追加してbundle install gem 'crummy' 基的な使い方 コントローラーでadd_crumbしてビューでrender_crumbs。 あとは家のExampleを眺めるとなんとなく分かると思う。 といっただけで終わらずのもなんなので、以下は動作に関するちょっとしたメモ。 パンくずリストの表示 – render_crumbs ビューのパンくずリストを表示したい場所にrender_crumbsを埋める。 多くの場合はレイアウトファイルに書けばいいと思う。 <%= render_crumbs %> render_crumbsにはオプションがいくつかあるが、おそらく使いたいのはセパレータの指定くらい。 (デフォルトのセパ

  • Rails3でTDD環境を整えたメモ - ひげろぐ

    2011/07/07追記 実はこの記事の内容よりも以下のGuardを前提にした構築がおすすめ。 Rails3+RSpec2+Spork+Guard(guard-rspec,guard-cucumber)で最速のBDD(振舞駆動開発)環境を作る | Curiosity Drives Me Guard便利すぎです。 久々にRailsでできる仕事が来たので久々に環境構築。 記事の一番最後に挙げた参考の渡り歩きつつ設定した。 Rubyのバージョンは1.9.2。Railsは3.0.5。 プロジェクトの作成 $ rails new -T hoge RSpecを使うのでUnitTestはいらないということで。 Gemfile 必要なものをBundlerでさくっと入れる。 group :development, :test do gem 'spork', '~> 0.9.0.rc' gem 'rspec-

  • Titanium Mobileを二ヶ月くらいさわってみた感想。 - ひげろぐ

    今年に入ってからほぼ毎日触ってました。でもほとんどiPhone開発しかしてない感想。 主観的なところをだらだらと書いてみましょう。 とりあえず気に入っているところイマイチと思うところを挙げてみたい。 合わせて総評など。 気に入っているところ さくさく開発できる Objective-Cとは段違いの開発効率。 冗長なメソッド名とメモリ管理の煩わしさからの解放がうれしい。 ちょっとしたモックアップ程度ならさくっと作れてしまう。 そこから開発者が作り込みに注力できる環境が見事にできあがっているのではないかと。 JavaScriptはくせもあるけどおおむね使いやすい言語。 CoffeeScriptとの組み合わせでさらにいいかんじ。 TDDできる Jasmineで気持ちよくTDD出来ている点が非常にポイント高い。 おかげでTitaniumラブですよ。 Objective-CでもTDD可能だけど、OCU

  • 1