タグ

ブックマーク / qiita.com/joker1007 (16)

  • vimでmarkdownのクォート内をシンタックスハイライトする方法とプラグイン - Qiita

    以下の記事に触発されて、vimmarkdownのクォートの中を上手くシンタックスハイライトさせる方法は無いか調べてみました。 RubyMineのシンタックスハイライトがすごかった件について - くりにっき Vim でコンテキストによって filetype を自動的に切り換えるプラグインをつくっている - C++ゲームプログラミング vim-preciousでも良さそうなのですが、最初からハイライトされてる方が自分好みだったので。 Vim Advent Calendarとして書けば良かったかもしれない。 別言語のシンタックス設定を読み込む function! MarkdownQuoteSyntaxGroup(filetype) let ft = toupper(a:filetype) return 'markdownCodeGroup'.ft endfunction function!

    vimでmarkdownのクォート内をシンタックスハイライトする方法とプラグイン - Qiita
  • 俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita

    ちなみに、最初に結論だけ言っておくと、まず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

    俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
    TokyoIncidents
    TokyoIncidents 2016/12/16
    "チームで開発している場合、レイヤーが持つ役割が自明である様にしなければならない。そして、その範囲を逸脱するようなコードを書いてはいけない" あらためてちゃんと読んだけど、これにつきる気がする
  • production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと - Qiita

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

    production環境でRailsアプリをdockerコンテナとしてECSで運用するために考えたこと - Qiita
  • embulk-output-influxdbを書いた - Qiita

    最近、データ分析と可視化の基盤構築をやってる関係で、GrafanaとinfluxDBについて調査してみようと思ったので、そのついでにRedshiftからinfluxDBにサマリーテーブルのデータを突っ込む際にembulkを使ってみようと思った。 既にあると思ってたinfluxDBへのアウトプット用プラグインが無かったので自分で書いた。 やっぱ、まだ新しいプロダクトだから色々と貢献の余地があるのは良い。 redshiftからinfluxDBへのデータ転送は手元で動作確認済みですが、とりあえず自分が今必要な機能だけ雑に実装したので、tagsを投入できなかったりエラー処理が適当だったりする。 (メトリクス収集とかじゃなくて、単純なサマリーを保存してるだけなので必要無かった) 落ち着いたらやるけど、必要な人はさっさと書いてプルリクしてくれる方が早いと思う。 jrubyでサクっと書けるのはありがたい

    embulk-output-influxdbを書いた - Qiita
  • Ruby製のシンプルなワークフローエンジンRukawaの紹介 - Qiita

    Bigqueryを使ったバッチジョブを色々と実行しているのですが、Rakeで複雑な依存関係を管理したり、並列実行させたりするのが辛くなってきたのでRukawaというワークフローエンジンを自作しました。 自作したのは、RailsプロダクトにAirflowとかLuigiとかAzkabanとか入れるにはちょっと重厚過ぎる感じだったのと、Rubyで書ける方が楽で良いやという理由からです。 RukawaとはRUby KAntan Workflow Assistantの略です(後付け) (当はミッチーとか水戸の方が好きなんだけど良い名前が浮かばなかった) 実際は、並列実行を可能にして書き方を変えてみたRakeとそんなに大差無い。 Rukawaの機能 ジョブの定義 まず実行したい処理をジョブクラスに記述します。 module ExecuteLog def self.store @store ||= {

    Ruby製のシンプルなワークフローエンジンRukawaの紹介 - Qiita
  • embulk bundleだけでJavaで書かれたプラグインをインストールし利用する方法 - Qiita

    以前embulkjava pluginをbundlerっぽくgithubからインストールして実行できるラッパーを作った - Qiitaという記事を書いた。 要はJava製のプラグインをgithubから直接インストールしてリリース前のものを使いたいというものだ。 で、コマンドをラップするgemを作ってみたのだが、DSLの挙動をちゃんと制御するのは面倒だしコマンドをラップするのは色々とポータビリティが悪い。 しかし、ある時天啓が降りてきた。 「Bundlerを弄ればいいや」と。 で、ソースコード読んで、gemspecの判別がどうなってるのかとモンキーパッチを当てるのにちょうど良い場所を探して試してみた所、とてもシンプルなハックで上手くいった。 Gemfile上でBundlerにモンキーパッチを当てるというダーティさに目を瞑れば割と便利ではないだろうか。 こんな風に書く。 require 'b

    embulk bundleだけでJavaで書かれたプラグインをインストールし利用する方法 - Qiita
  • タイプキャスト付のattr_accessorを作った - Qiita

    車輪の再発明感が凄いというか、active_attrを使っとけばいいのでは、という説があるのだが、attr_accessorにタイプキャスト機能を追加したgemを作ってみました。 joker1007/attr_typecastable 前に書いた Ruby - ActiveModelを活用するための属性定義拡張系gemについて - Qiita というネタで紹介してるgemは基的にこの機能を持ってます。 ただ、色々と余計なことやり過ぎてて細かく調整しようとした時に、ソースが読みにくい。 今更新しいgemとして作る程のものでもないんですが、コードベースが軽量で機能を限定したものを自前で用意しておいた方が、自分としては楽だろうと思ったのでgemにしてみました。 多分、active_attr, virtus, attrio等と比べてコードベースはめっちゃ小さくなってます。 その他のgemは色々と

    タイプキャスト付のattr_accessorを作った - Qiita
  • embulkで処理する各レコードにprocを適用して加工するembulk-filter-ruby_procを作った - Qiita

    embulkのプラグインを一つ作りました。 joker1007/embulk-filter-ruby_proc embulk-filter-eval というプラグインがあって、Rubyのコードをそのままevalするんで何でもできるんですが、一レコード毎に毎回evalするのはデータ量多くなってくると効率悪いだろうと思い、もうちょっと自由度下げても良いならprocだけ事前に準備してしまえばいいだろうという発想で作ったプラグインです。 もう自由に何でもかんでもやりたい場合は、filter-evalを使いましょう。 config # ... filters: - type: ruby_proc requires: - cgi columns: - name: data proc: | ->(data) do data["events"] = data["events"].map.with_inde

    embulkで処理する各レコードにprocを適用して加工するembulk-filter-ruby_procを作った - Qiita
  • EmbulkでMySQLからBigQueryに入れ子になったJSONファイルを直接インポートする方法 - Qiita

    {"id": 1, "nickname": "joker1007", "comments": [{"id": 1, "body": "comment body"}, {"id": 2, "body": "next comment"}] SELECT CONCAT( '{', '"id":',users.id, ',"nickname":',IF(users.nickname, CONCAT('"', users.nickname, '"'), "null"), ',"comments":',CONCAT('[', GROUP_CONCAT((CONCAT('{"id":', comments.id), CONCAT(',"body":"',comments.body,'"}')), ']'), '}' ) AS payload FROM users INNER JOIN comments

    EmbulkでMySQLからBigQueryに入れ子になったJSONファイルを直接インポートする方法 - Qiita
  • Bigquery上で実行するバッチ処理のテストコードを書く (Ruby編) - Qiita

    bigquery上でデータを加工して集計する時、このSQL当に合ってんのかテストコードで検証したくなる。 しかし、こういう外部サービスを使った処理のテストコードを書くのはとても面倒臭い。 とはいえ、書かんわけにもいかんし、実際に動かしてみないと分からないこともあるので、実際にbigqueryで処理を実行してテストする方法をまとめてみる。 テストデータのロード bigqueryにデータを突っ込む方法はバルクロードするかStreaming Insertの二つ。 しかし、バルクロードはテストコードを書く時に困るのが、データ量に関わらず処理に一定時間かかること。 どれだけ小さいデータでも最低1分前後は待たされる上に、時々謎の刺さり方をして最悪数分かかる場合がある。 一方でStreaming Insertはまずテーブルを作っておかなければいけないし、Streaming Insertのレスポンスが

    Bigquery上で実行するバッチ処理のテストコードを書く (Ruby編) - Qiita
  • YAML生成を工夫してembulkの設定ファイルを使い易く - Qiita

    embulk meetupの後にsonots先輩に何か書いてくださいよーって言われたので、 embulkに限った話ではないのですが、関連する話題なのでEmbulk Advent Calendarに書かせてもらおうと思います。 embulkは設定ファイルがYAMLです。 現時点ではテンプレート機能はまだ限定的な機能しかなくて、それ程表現力がありません。 それならもう、YAMLの生成を別に任せようと思って簡単なgemを作りました。 joker1007/yaml_master YAMLの設定ファイルの大になるマスターファイルを作っておいて、そこから特定の範囲だけを別のYAMLとして出力するだけのgemです。 その際にerbでRubyを埋め込めるようにしているので、Rubyで表現できることは何でもできます。 環境変数から日付を取ってそれをRangeにしてループしたり、ActiveRecordから

    YAML生成を工夫してembulkの設定ファイルを使い易く - Qiita
  • Real World Refinements - Qiita

    Ruby AdventCalendarの最終日です。 締切をオーバーしました……。orz Refinementsの使い道が無いとか、使ったことがないという人が結構居るみたいなので、いくつかのユースケースを紹介しようと思います。 テストコードのDSL 一つはrspec-parameterized。 # Table Syntax Style (like Groovy spock) # Need ruby-2.1 or later describe "plus" do using RSpec::Parameterized::TableSyntax where(:a, :b, :answer) do 1 | 2 | 3 5 | 8 | 13 0 | 0 | 0 end with_them do it "should do additions" do expect(a + b).to eq answ

    Real World Refinements - Qiita
  • ActiveRecordの読み込みが実際にトリガーされた場所をログに記録するgem - Qiita

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

    ActiveRecordの読み込みが実際にトリガーされた場所をログに記録するgem - Qiita
    TokyoIncidents
    TokyoIncidents 2015/04/16
    これ良さそう
  • Railsと周辺のTimeZone設定を整理する (active_record.default_timezoneの罠) - Qiita

    まず、ここまでで一旦整理する。 Time.nowはRubyの組み込みなのでシステムのタイムゾーンしか見ない。OSの時間と常に一致する。Time.localの出力結果もOSのタイムゾーンと一致する。 TimeWithZoneクラスはconfig.time_zoneに左右される。 Ruby組み込みのメソッドで取得したUTCの時間を基準に、設定されているタイムゾーンの時間に変換する。 ActiveRecordのインスタンスに対してアクセサを利用して時間をやり取りする場合はTimeWithZoneで行われる。 仮にTimeクラスを渡しても代入時にTimeWithZoneに変換される。 config.active_record.default_timezoneの設定はDBを読み書きする際に、DBに記録されている時間をTime.utcで読むかTime.localで読むかを設定する。 :utcの場合DB

    Railsと周辺のTimeZone設定を整理する (active_record.default_timezoneの罠) - Qiita
  • Sprockets再考 モダンなJSのエコシステムとRailsのより良い関係を探す - Qiita

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

    Sprockets再考 モダンなJSのエコシステムとRailsのより良い関係を探す - Qiita
  • これを読むとRSpecの裏側がどうやって動いているのか分かるかもしれないぜ - Qiita

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

    これを読むとRSpecの裏側がどうやって動いているのか分かるかもしれないぜ - Qiita
  • 1