CircleCI上でCapybara, Poltergeist, PhantomJSを利用したテストがMouseEventFailed失敗す... - Sooey
CircleCI上でCapybara, Poltergeist, PhantomJSを利用したテストがMouseEventFailed失敗する問題を解消した。 以下のような構成のRailsアプリをCircleCI上でビルドすると、Capybara::Poltergeist::MouseEventFailedという例外が発生してテストが失敗するケースがあった。 Rails 4.2.x RSpec 3.4.x Capybara 2.6.2 Poltergeist 1.9.0 PhantomJS 2.1.1 (CircleCIのプロジェクト設定でUbuntu 14.04 (Trusty) containerを利用するように設定しておく必要あり) この時、失敗の原因となっているテストコードは、 click_link '日本語のラベル' のようなもの。 調査のためにCircleCIにSSHで接続し、
RSpec 3.0でのコレクションに対するマッチャーの使い分けメモ。 - Sooey
RSpec 3.0でのコレクションに対するマッチャーの使い分けメモ。 コレクションに値が含まれることの検証: expect([a, b, c]).to include(a, b) # Success expect([a, b, c]).to include(d) # Failure コレクションの要素が完全に一致することの検証: expect([a, b, c]).to contain_exactly(c, b, a) # Success expect([a, b, c]).to contain_exactly(c, b) # Failure コレクションの要素と順序が完全に一致することの検証: expect([a, b, c]).to match([a, b, c]) # Success expect([a, b, c]).to match([a, c, b]) # Failure
BEM-Methodology Definitionsの日本語訳。 - Sooey
BEM-Methodology Definitionsの日本語訳。 YandexのBEM-Methodologyが方法論としてあちこちで参照されているのを見かけることが増えてきて、ちょっと変わったCSSの命名規則、みたいな認識が持たれるようになってきた。 しかし、原典である「BEM-Methodologyとは一体何なのか」という情報はなかなか説明されず、このままだとBEMを導入するチーム内で齟齬が生まれることもあるだろう、ということで、HTML/CSSマークアップに適用する際のエッセンスとなりそうなDefinitionsというページだけ日本語に訳した。 https://github.com/juno/bem-methodology-ja 最初は本家サイトのリポジトリをforkして作業していたのだけど、どうもCMSというかHTML生成のプロセスがYandexの独自ツールを使っていて、表示確認
37signalsのBasecampでは、Railsで用意されているデフォルトの3つの環境のほかに、Beta、Staging、Rollout... - Sooey
37signalsのBasecampでは、Railsで用意されているデフォルトの3つの環境のほかに、Beta、Staging、Rolloutの3つを定義して使っている。 Beyond the default Rails environments by David of 37signals Rollout環境は、新機能をまずユーザーの10%にだけ公開するために使われるもので、Flickrやetsyなど多くのサイトではFeature flippersとよばれる機構で実現している（機能毎のフラグを参照することで、新機能をユーザーに提供するかどうか切り替えるようなもの）。コメント欄でも、何故、Feature flippersではなく環境で機能のロールアウトを行うのかが尋ねられていて、DHHは以下のように回答していました。 I always want to leave the campsite in
Basecampを家族で使っている人の話。 - Sooey
Basecampを家族で使っている人の話。 How we - the Kims - use Basecamp at home by Dan Kim of 37signals この人は37signalsのスタッフではあるけれど、入社前から何年もBasecampを奥さんとの情報共有に使っているそうです。最近Discussionの数が1,000を超えているのに気づいたので、簡単なまとめ記事を書いた、ということのよう。 個々の使いこなしについては、スクリーンショットもあるので原文を参照してもらうとして、とくにいいなと感じたのは後半の "So what’s the real benefit of doing all this?" のところ。 Like many couples, my wife and I both work. We’re together as a family for maybe
Hashrocketではどのようにペアプログラミングを実践しているのか（HashrocketはObie Fernandez氏が創業したWeb... - Sooey
Hashrocketではどのようにペアプログラミングを実践しているのか（HashrocketはObie Fernandez氏が創業したWeb開発会社）。 How We Pair - The Hashrocket Blog Hashrocketでは常にペアプログラミングを行なっており、受託案件の重要な機能を開発するときも、オープンソースフライデー（毎週金曜日にオープンソースコードを書く的な催し？）でオープンソースのコードを書くときも、常に2人体制だそうだ。 1つの頭よりも2つの頭で考えるほうがより良い、という当然の理由のほかに以下のような理由がある。 間違ったやりかたにはまってしてしまう前に、パートナーが別な解決策を提示してくれる 正しい解決策がずっと目の前にあるのに、それとは別の難問に取り組み続けてしまうような時、解決策がそこにあることをパートナーが教えてくれる スペルミスのような単純な部
ActiveSupportのassert_valid_keysでHashのキーをチェックする。 - Sooey
ActiveSupportのassert_valid_keysでHashのキーをチェックする。 ActiveSupportで提供されているHash#assert_valid_keysを使うと、メソッドの引数として渡されたHashに必要なキーが含まれているかどうかを容易にチェックできる。 { :name => "Rob", :years => "28" }.assert_valid_keys(:name, :age) # => raises "ArgumentError: Unknown key: years" { :name => "Rob", :age => "28" }.assert_valid_keys("name", "age") # => raises "ArgumentError: Unknown key: name" { :name => "Rob", :age => "28
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので読み返してみました。 Testing like the TSA by David of 37signals（TSAはTSAロックのTSAですね。RailsConf行く時に買った） 予想通り、DHHはなんでもかんでもテストを書くということに対してはだいぶ批判的なスタンス。 曰く、テストを書くということの裏側には、テストを書く時間、テストをアップデートする時間、テストコードを読んで理解する時間といったコストが発生しているので、テストを書くことによって得られるメリット（回避できる問題）とのバランスをよく考える必要がある、と。 議論を呼ぶことは承知のうえでDHHが提案する「Railsアプリのテストにおいて、やってはいけない7つのこと」は以下の通り。 100%の
ジャック・ドーシー(Jack Dorsey)氏についての日本語の情報を集めてみた。 - Sooey
ジャック・ドーシー(Jack Dorsey)氏についての日本語の情報を集めてみた。 ジャック・ドーシー氏は「Twitterの発案者＆モバイル決済プラットフォームのSquareの創業者」という感じで知られているけれど、その人となりを調べてみるとかなり興味深い人物だったので、メモ代わりに日本語でドーシー氏のことを紹介しているページを集めてみた。 hsakawa's Radar — ジャック・ドーシーの『ツィッターは第一幕』（Vanity Fair） こちらのブログでは、Vanity Fair誌に掲載されたドーシー氏に関する記事をかなり詳細に紹介されている。 「世界的に著名な有力者や芸能人と親しく、プラダのスーツを愛用し、有名なフランス人バレリーナと浮き名を流す、若き億万長者」といえば、扱い方によってはずいぶんとイヤったらしい人間として描くこともできてしまいそうな対象に思える。だが、記者はこうい
会社を作って1週間が経ちました。 - Sooey
会社を作って1週間が経ちました。 ずっとフリーランスという体（てい）でWebエンジニアをやってきましたが、1年ほど前にビジネスとして取り組んでみたいサービスを思いついてしまったので、去年からいろいろ準備をしてきて、1月11日に@mochizさんとQNYP（合同会社キュニップ）という会社を始めました。 コーポレートサイトは http://about.qnyp.com/ になります。 URLがqnyp.comじゃなかったり、ロゴがあんまり企業っぽくなかったりするのは、「qnyp.comでキュニップというサービスを運営する」というのが目的だからです。しかし残念ながらサービスはまだまだ開発中ですので、当面はTitanium MobileでのiPhoneアプリ開発に業務として取り組んで行きたいなと思っています。 超スモールスタートなのでまだオフィススペースはなくて、ぼくの自宅を作業スペースにしたり、
Webアプリケーションへのエントリポイントは1つだけとは限らない。たとえば、一般的なRailsアプリケーションなら、Webサーバープロセスへ... - Sooey
Webアプリケーションへのエントリポイントは1つだけとは限らない。たとえば、一般的なRailsアプリケーションなら、Webサーバープロセスへのリクエスト経由で動き出す場合と、delayed_jobやResqueといったジョブキューのワーカープロセス経由で動き出す場合があったりします。 普段、開発環境なんかではrails serverしつつ別ターミナルでrake jobs:workしておいたりしますが、HerokuのDavid Dollarさん（He also maintains heroku.gem!）がリリースしたForemanというgemを使うと、こういった複数の種類のプロセスを一括して管理できるようになるみたいなので、試してみました。 まず、foremanをインストール。 $ gem install foreman 例えば、delayed_jobを使ったRailsアプリケーションの場
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、... - Sooey
AWSの障害に起因したHerokuの障害について、Herokuによるレポートが公開されたので要点を翻訳しました（全訳ではありません）。「だ、である」調にしたため多少偉そうに見えるかもしれませんが、原文はとても誠実な表現で書かれていますので、その点は誤解なきよう。 一部、文意が汲めなかった部分は原文を併記していますので、ご意見・ご指摘などがありましたら@junyaまでお願いします（@irohirokiさん、アドバイスありがとうございます）。 Resolved: Widespread Application Outage Herokuを4年間運用してきて最大の障害 専用データベースを利用している大規模アプリケーションでは最大16時間のダウンタイム 共有データベースを利用している小規模アプリケーションでは最大60時間のダウンタイム アプリケーションのデプロイについてはプラットフォームの広範囲にわ
GitHub, Inc.のmojomboことTom Preston-Werner氏が2008年の12月に書き上げてそのままお蔵入りにしていた... - Sooey
GitHub, Inc.のmojomboことTom Preston-Werner氏が2008年の12月に書き上げてそのままお蔵入りにしていた、「GitHubの1年目から学んだ10の教訓」というエントリが公開された。 Ten Lessons from GitHub's First Year 10の教訓は以下の通り。詳細は元エントリをご覧ください。 早く始める (Start Early) 顧客に合わせる (Adapt to Your Customers) 楽しむ (Have Fun) Twitterに注意をはらう (Pay attenton to Twitter) 意のままにデプロイする (Deploy at Will!) オフィスはいらない (You Don't Need an Office) オープンソースを通じて雇う (Hire Through Open Source) チームを信じる
GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充... - Sooey
GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充実機能はありません）。 ためしに、巷で話題のamatsuda/kaminariのテストをcijoeで実行してみましょう。 まずはcijoeをインストール。 $ gem install cijoe 手元のSnowLeopard + Ruby 1.9.2だとkaminariのbundle install中にlinecacheのインストールでコケてしまうので、1.8.7を使います。 $ ruby -v ruby 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin10.5.0] まず、ビルド対象のリポジトリをローカルに持ってきて、rake specが成功するところまで確認します。 $ git clone https:/
Mongoid 2.0.0.rc6から2.0.0.rc7での変更点。 - Sooey
Mongoid 2.0.0.rc6から2.0.0.rc7での変更点。 色々と変更点はあるのだけど、日本人的に一番大きいのは、Commit eb3f35f84bc73b7346f5189e80b437c2764c1be2 to mongoid's mongoid - GitHubの"mongoid should use :mongoid i18n scope instead of :activemodel"ではないかな。 rc6まではconfig/locales/ja.ymlに activemodel: attributes: user: email: "メールアドレス" という翻訳文字列が定義されていた場合、 I18n.locale = :ja User.human_attribute_name :email # => "メールアドレス" となっていたのですが、rc7からは mongoid
Sooey - なぜ日本のネットベンチャーはエントランスばかりが小奇麗で、執...
なぜ日本のネットベンチャーはエントランスばかりが小奇麗で、執務スペースは養鶏場のような有様なのでしょうね。執務スペースだけはクリエイティビティが感じられない。転職準備金200万円よりも、もっとゆったりしたデスクを用意したほうがよっぽど効果あると思うのだけど。 ディー・エヌ・エーさん、執務スペースは広いけどデスクが縦横にずらり。 blog::941:株式会社ディー・エヌ・エーに行ってきた！ Googleワナビーなオフィス造りがちょっと気になるグリーさん（初代サーバーの展示とか）、執務スペースだけはいかにも日本のオフィスという感じで残念。 blog::941:グリー株式会社 に行ってきた！ エントランスなどがアーティスティックでシャレオツなスタートトゥデイさん、執務スペースは広いけどデスクはギッチリ詰まって並んでて残念。 blog::941:ZOZOTOWNで有名な 株式会社スタートトゥデイ
RSpecで書いているスペック（テスト）がどうも冗長になっている気がして、いいテストのリファクタリング指針はないかなと探してみたところ、RS... - Sooey
RSpecで書いているスペック（テスト）がどうも冗長になっている気がして、いいテストのリファクタリング指針はないかなと探してみたところ、RSpecのベストプラクティスをまとめているページを2つほど見つけたのでまとめておく。 (My) RSpec best practices and tips | EggsOnBread specify {}やit {}、subject {}といったショートカット記法を使う contextを'when'や'with'で始めて、メソッドの説明には'#'を使う エラーメッセージがわかりやすくなる メッセージをわかりやすいものにするためにRSpecマッチャーを使う 1つのitブロックには1つのExpectationだけを記述する describeとcontextをふんだんに使う 妥当な値、境界値、不正な値をテストする My top 7 RSpec best pra
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
