AWSの新しいロードバランサであるNLB(Network Load Balancer)を使ってfluentdのforwardパケットを分散してみたので、レポートをまとめておく。 NLB自体については、クラスメソッドのブログ等で紹介されているのでそちらを参照するのが分かり易い。 静的なIPを持つロードバランサーNetwork Load Balancer（NLB）が発表されました！ 試してわかった NLB の細かいお作法 ざっくり言うと、TCPプロトコルを対象にしたALBって感じ。 ターゲットグループはポートレベルで設定できるので、コンテナ環境と相性が良い。 ポート違いで複数fluentdが立っていても同じグループとしてまとめて分散できる。 利用までの流れ ターゲットグループを作成し、TCPレベルでコネクションが貼れるかのヘルスチェックの設定をする インスタンスもしくは対象IPと、ポートの組を

ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ

実際には、まだ本当の本番環境では運用できてなくて開発用のステージングで運用が開始できたぐらいで、他にもやること一杯あるんだけど、ある程度知見が溜まったのでまとめておく。 ちなみに、規模はそんなに大きくないがデータ量は多いアプリケーションで運用環境はAWSのECSを想定しており、現時点で普通のEC2ノードとコンテナで並行稼動している。 docker-swarmなりで自前でコンテナプールを構築してもいいのだが、そうするとサービスディスカバリとか考えなければいけないことが増えるので、後回しにしている。 (注: かなりサービス固有の事情が含まれるため、もし参考にされる方が居たとしても、そのままの形では適用できない可能性が高い) 追記: RailsアプリのためのDockerfileとdocker-compose.ymlのサンプル - Qiita コンテナ化のモチベーション CentOSのお守りからの

以前Nodeで作っていたものをElectronで作り直していて、同じ問題にまたハマったので書いておく。 所謂、UTF-8-MAC問題である。もう遥か昔にNodeでハマった時の記事がある。 node.jsでUTF-8-MACを扱う - joker1007の日記 Macのファイルシステムはファイル名に対してNFDとかいう正規化を行っていて、ファイルシステムにアクセスする時に勝手に変換しやがる仕組みになっている。 このせいで、濁点が入ると急に死ぬとか、本当辛い問題が起きる。何の嫌がらせなんだと……。この世界は文字が8ビットで済む様な国ばっかじゃねえんだよ！ とりあえずMac NFDでググると辛いのは俺だけじゃない気持ちになれる。 で、昔は上で貼ったブログに書いたような方法で解決していたのだが、正直、この解決策は2015年にもなって面倒過ぎるだろと思っていた。 (マジかよーってググって自分の記事が

ActiveRecordは必要になるまでDB読み込みをしません。 なのでやたら複雑なビューの中でクエリを弄ったり、コントローラーが肥大化してる状態でひどいSQLがログに流れてくると、パっと見ではどこが原因なのかすぐに分からない。 なので、SQLが実行された時にそれが実際にトリガーされたソースコードの位置も一緒にログに吐いてくれるgemを作りました。 bulletで分からないような、ビューのループの中で直接モデル読んでるみたいなヤバイ箇所を速やかに見つけるためのものです。 joker1007/activerecord-cause 仕組み的にはActiveRecordのロギングの仕組みを丸パクリしてcaller_locationsを足した感じ。 全ての読み込み位置を表示するわけではなく正規表現でマッチするパスを持ったソースコードの位置のみをログに記録します。 Railsで利用する場合は自動的に

すいません。締切守れませんでした…。 やっぱ、java-jaの忘年会の翌日は辛い…。 はじめに Webシステムを開発していると切っても切れないのがJavaScriptです。 Railsはかなり早い時期からalt-JSや結合、minify等を組み込めるようにフレームワークにそれを取り入れてきました。 それを支えているのがRails3.1から導入されたsprocketsです。 それに伴なってJSのライブラリをどうやって管理するかという点について、独自の路線を取ることになりました。 JSのライブラリを同梱したgemパッケージにラップしてrubygemsとして管理する方法です。 ある程度は上手くいっていたし、今もその流れは続いているんですが、時々問題になることもあります。 例えばメンテナの対応時期がズレてて古いバージョンのままだったり、似たようなgemが乱立してややこしくなったり。(backbon

これはTokyuRuby会議08にて発表した資料を元にQiita向けに再編集したものです。 元々Advent Calendarと共用にしようと思って、どう考えても5分で話せない資料でLTしたのでした。 最初に RubyのテスティングフレームワークとしてはトップクラスにメジャーなRSpecですが、内側の実装が黒魔術感に溢れていて非常に読み辛い。 そしてカスタマイズするにも学習コストが高いという話を聞きます。 最近「RSpec止めますか、人間(Rubyist)止めますか」みたいな風潮が出ていてバリバリのRSpec派の私としては見過ごせない感じになってきたので、いっちょRSpecがどんな感じで動いてるのかを大まかに解説していくことで、世の中に対して再びRSpecを啓蒙していこうと思うわけです。 この話はrspec-core-3.1.7辺りをベースにしています。 起動 rspecのコマンドエンドポ

本当は、RubyWorld Conf辺りでこういう内容も交えてなんか話せればいいなあと思ってたんだけど、CFPに落ちたのでQiitaにポエムを書いてみました。 Railsはそれなりに学習コストはかかりますが、慣れてくるとデフォルトで便利なものが揃ってるしサードパーティライブラリも豊富で、未だに最も便利なWebアプリケーションフレームワークの一つだと思います。 なので、最近のスタートアップ界隈ではRailsで開発をスタートする、という話をよく耳にします。(個人の感想です) しかし、Railsは本体に新しい要素をガンガン取り入れてくるので、バージョンアップのサイクルはかなり早く、それに追従していくのはそれなりに大変です。 Railsで開発をする場合には、一旦レールに乗ったらプロダクトが死ぬまで走り続ける覚悟が必要です。(時速60km以下になったら爆発する) それを最初に理解しておかないと、あっ

てめえらのRailsはオブジェクト指向じゃねえ！まずはCallbackクラス、Validatorクラスを活用しろ！RubyRails ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。

いよいよRSpec3時代が近付いてきました。 betaとかrcで新しいバージョンが出る度にハマり所を仕込んでくるので、そろそろ落ち着いて欲しい所です。 RSpec3は表記の変更だけでなくて内部実装をがっつりリファクタリングしてるため、Formatterの作りも結構変わっています。 カスタムFormatterを自分で作ってる人とかForkして改造する人以外にはあんまり関係無いかもしれませんが、一応どう変わったのか書いておきます。 (そもそもそういう人は自分でソース読むし……) Formatterの基本となるクラスはRSpec::Core::Formatters::BaseFormatterというクラスです。 これは2系でも3系でも変わってません。 RSpec3系で大きく変わったのは、Formatters.registerというメソッドを呼び出してFormatterクラスを登録しなければいけな

GitHubを彷徨っていてよくあるのが、ググったりRuby Toolboxとかで見つけて「これイイじゃんよ！」と思ったら既にスター済み、という奴。 一回、自分がどんなリポジトリにスター付けたのか整理しつつ、更新止まってたり古くなったやつを削除していこうと思う。 それぞれの説明は超適当。基本的にいつか使おう的な感じでスターを付けているので、あんまり使ったことあるのが無い。 そもそも良く使うものにはスター付けてないこと多いし…。 大体rubygemsで一部JSのライブラリ、少しvimとScalaって感じ。 思い返したようにスター付けてたので、時期がバラバラだけど、基本的に下に行く程付けた時期が新しい。 リポジトリ 説明

Rails 4.0.0がリリースされたので今参加しているプロジェクトのアプリのアップデートが出来るかを試してみました。 やってみた結果としては、2.3 -> 3.0や、3.0 -> 3.1に比べると大分楽にバージョンアップできる感じです。 たまたま今のプロジェクトで引っかかった問題について、メモがてらまとめておきます。 rake rails:update diffを見ながらconfigファイルを書き換える。 そんなに大きな変更は無い。 rails4からはinitializerに色々移せって感じで、application.rbが軽量化されてるけど、元のままでも別に問題無い。 設定項目の重複だけ注意。 strong_parameters 元々、gemで先行導入して取り入れていたので概ね問題無く移行できました。 attr_accesibleを利用したセキュリティ対策は、外部のgemに分離されてい

もしかしたら、Rubyに慣れてない人には気付いていない人も居るかと思ったので、 カジュアルにRubyGemsを活用する事のメリットについて書いておきます。 普通、Rubyのgemパッケージは、gem installでインストールできるようにrubygems.orgにホスティングしておくのが基本です。 とは言え、世界的に公開されるものなので、ちゃんとgemとしての体裁を整えておかないと何か恥ずかしいし、説明とかも英語でちゃんと書いとかないと、って考えると面倒なレベルのツールとかあると思います。 API叩くための簡易コマンドとか、社内ツールの処理自動化とか。 しかし、Bundlerとgitのおかげで、現在はそういった事を余り気にする必要が無くなっています。 Bundlerは、gitリポジトリから直接コードをクローンして、パッケージ化されたgemと同様に扱う事ができます。 参考: Bundler