Qiitaに「あなたはDRY原則を誤認している?」を投稿しました
Ruby on Rails の普及とともに広まった感のある「DRY原則」を多くの人は間違って認知している。 頼むから間違えないでくれという願いが込められた、最近流行りのエンジニアポエムです。
Railsの開発用サーバをPowからPuma-devへ乗り換えた
Rails5からデフォルトRackサーバがPumaになりました。開発用のサーバとして自分はずっとPowを使っていましたが、Pumaを使っているのであればPowではなくpuma-devが主流になっていると知って調べてみたところ、PowからPuma-devへの乗り換えを即決しました。 個人的にいいなと思ったのは以下の点。
- Pow同様「zero-config Rack server」である
- Websocketsをサポート
- Linux対応(全機能を使うには追加のインストールが必要)
- 開発が活発(Powは実質開発が止まっている)
- powder相当のコマンドがPuma-devにはデフォルトで組み込まれている(puma-dev link)
Macでのインストール手順は以下のとおり。
$ curl get.pow.cx/uninstall.sh | sh # Powのuninstall $ brew install puma/puma/puma-dev $ sudo puma-dev -setup $ puma-dev -install
これだけ。使い方は基本的にPowを踏襲していて、移行はスムーズにいけます。
$ cd /path/to/my/app; puma-dev link -n appname # Rackアプリを登録(~/.puma-devへシンボリックリンクを貼る) + App ‘appname' created, linked to '/Users/hoge/.puma-dev/appname'
http://appname.dev or https://appname.dev へアクセスできるようになります。 サーバの再起動もPowのままで、tmp/restart.txtをtouchするだけ。 また、puma-devにシグナルを送れば全アプリを一気に再起動できる。
$ touch tmp/restart.txt # サーバ再起動(Rackアプリの直下で実行) $ pkill -USR1 puma-dev # 全アプリを再起動
しかしPowもそうだったけど「zero-config」で快適に使えるソフトって素晴らしいですね。 例えばfish shellもデフォルトの設定でかなり使えるという触れ込みなので、zshから移行しようかなと思ってたりします。
広告配信サービスで自分がやりたかったこと
ここ数年、自分が思っていたことが書かれているブログを見つけた。 (2015年5月時点でのDSPの状況について書かれているブログだけど、本質的なところが自分に響いた。ということです。DSPに関しては自分も将来性のあるサービスだとは思っています。)
アドテク業界の動きをみていると、アドテクにとらわれてビジネスの基本を疎かにしていることが多いように見えます
広告配信サービス成長法の基本 - DSPはなぜアドネットワークに勝てないのか
自分は約3年半ほど某アドテク系企業で働いていました。基本的に管理画面の開発を担当していました。(今年の5月に退職) この期間はちょうどDMPやDSPが広がっていった時期と被っていて、まさに引用した内容の通り「アドテクにとらわれて」開発をしていたなと思います。 バズったキーワードがあると飛びついて実装する感じですかね。社内も社外もアドテクに詳しい人達が率先してそんな動きをしている感じでした。 アド系の知識が乏しい僕はアドテク業界ってそういうものなのかなぁ、と思いながらコードを書いていたけど違和感を感じていた事も事実で、 これってユーザーの望んでいる事なのか?流行りに飛びつくんじゃなくて、もっと本質的な事に力を入れるべきなのでは? 自分の場合それは・・・
使いやすい管理画面の提供など
- 広告主の業務を効率化すること
使いやすい管理画面の提供など
- メディアの業務を効率化すること
マッチングの精度を上げること、広告表現方法を増やすこと、コンサル、など
- 広告価値・メディア価値を高めてあげること
以上のことが優位で実力があれば、広告予算は増え、メディアの掲載枠も増え、口コミで実力が伝わります。広告配信サービスを一定規模以上に成長させるにはこの実力が必須条件です。
広告配信サービス成長法の基本 - DSPはなぜアドネットワークに勝てないのか
「使いやすい管理画面の提供など」 これ!管理画面担当だったし、まさにこれをやりたいと思っていた。 UIの改善をしていって、どんどん使いやすい管理画面にブラッシュアップをしていくようなイメージですね。 自社サービスを提供している会社に入れば、それが出来ると思っていた。 ところが実際は新機能の実装を優先したいという勢力が強く、自分の提案は通らないことが多かったのが現実でした。 ・・・ただ、新機能や新システムに力を入れたくなる気持ちも分かるんです。 新機能を実装すればメディアにプロダクト名が出たり、それをキッカケに営業がしやすくなったりするからついそうなってしまう。 他社もやっているわけで、自分のところだけ作らないわけにはいかない・・・という状況もある。
ここでどう動くかが勝負の分かれ目だったのかもしれない。ネンドさん、アイモバイルさんは正しい選択をとった。
「ネンド」「アイモバイル」強者の共通点 - DSPはなぜアドネットワークに勝てないのか
- ①配信方法が枠毎の広告効果によって枠毎に入札単価を自動で変動させる ※DSPは配信先を人を中心に決めます ※配信方法は選べる
- ②DSPが流行る前からサービス開始 2社共DSPが流行る前から広告配信サービスを行っており、高度なアドテクを使わない時代に、いかにCPAを下げられるか考え抜いてきた歴史があります
- ③管理画面が使いやすい
この2社はユーザーファーストでプロダクトを成長させたのではないかと考えている。「ユーザーは何を望んでいるのか?」が論理の出発点になっているのではないだろうか。だからいい結果が出たのだ。 ユーザーファーストって当たり前のことだと思っていたのだけれど、これが出来ている会社って実は少ないんですよね。技術は面白いし、大事だけれど、踊らされてはいけない。最近ウェブ界隈も技術の進化が加速していて盛り上がっているけど、あくまでも"ユーザーファースト"でプロダクトを作っていきたい。
大江戸Ruby会議05に行ってきた
大江戸Ruby会議05に行ってきました。 午前中はRubyのI/Oの話(実装の話です)から始まって、CとかGoのソースコードばかり出てくるLTが続いたので非常にasakura.rbぽいなーと思いつつ聞いてました。 午後もやっぱり濃い内容だったけど、TwitterのTLでは江渡浩一郎さんの「共創コミュニティのデザイン」が一番沸いてた感じありますね。パタン・ランゲージが建築業界で衰退していった理由のくだりなどは想うところありました。 あと、山崎さんのNinjaTalkディスプレイ広告領域カオスマップが出てきた時違和感を感じたwあれっ?って。RubyKaigiでアレを見るとは思わなかった。そういえばスケールアウトさんってRubyな会社だよなって気付いたけど。
React.js meetup #2に行ってきた
勉強会の募集って、使ってるサイトがバラバラで自分で出た勉強会を時系列で一覧できない。 とう問題点があるので自分でサービスを作りました・・・と思ったけどAPI連携バリバリになると保守とか保守とか保守とかあるのでちょっと今の状況では厳しそうなのでパス。 これからは参加した勉強会が分かるだけでいいので、どこに行ったかだけでもブログに書くことにする。
React.js meetup #2を開催しました - blog.koba04.com
そんなわけでReact.js meetup #1にも行ったんだけど、今回は#2をやるってことで行ってきた。#1ではReact.jsやJavascript周辺における最近の動向まとめ的なスライドが多かったという印象で、今回はReact.jsの業務での導入事例が増えてきたなと感じました。
個人的に一番おもしろかったのは@teppeisさんがViktorさんに向けて作ったスライドなのに、Viktorさんが早めに帰ってしまっていなかったことですね。
ActiveRecordで引数があるscopeはクラスメソッドで定義しろ!
タイトルの通りActiveRecordでscopeを使う場合、引数が必要であればクラスメソッドを使うことがRails Guideで推奨されている。 これを知ったのはかなり前のことで、その時から自分は引数を受け取るscopeをクラスメソッドとして定義しています。
class Article < ActiveRecord::Base def self.created_before(time) where("created_at < ?", time) end end
Using a class method is the preferred way to accept arguments for scopes. These methods will still be accessible on the association objects:
category.articles.created_before(time)
Active Record Query Interface — Ruby on Rails Guides
推奨されているだけであって、別にscopeを使いたければ使ってもいいのだけど、今となってはnamed_scopeを使えば遅延評価が便利〜。とかクラスメソッドでも同じような(厳密には違うけど)ものだし、自分の場合scopeで定義するのは
# 編集可能な記事 scope :editable, -> { where(state: 'editable') }
のように、アプリの多くの場所から呼びされシンプルな絞り込みの条件だけで使うようにしています。
Rails俺は気づかなかったシリーズ「改行コードをHTMLタグに置換」
文字列の改行コードを
タグに置換したい!とかよくある事だったので、毎回helperに#brとかメソッドを定義していたけど、simple_formatというヘルパが既に定義されていた。
my_text = "Here is some basic text...\n...with a line break." simple_format(my_text) # => "<p>Here is some basic text...\n<br />...with a line break.</p>" simple_format(my_text, {}, wrapper_tag: "div") # => "<div>Here is some basic text...\n<br />...with a line break.</div>" more_text = "We want to put a paragraph...\n\n...right there." simple_format(more_text) # => "<p>We want to put a paragraph...</p>\n\n<p>...right there.</p>" simple_format("Look ma! A class!", class: 'description') # => "<p class='description'>Look ma! A class!</p>" simple_format("<blink>Unblinkable.</blink>") # => "<p>Unblinkable.</p>" simple_format("<blink>Blinkable!</blink> It's true.", {}, sanitize: false) # => "<p><blink>Blinkable!</blink> It's true.</p>"
全然気づかなかったこれ。Railsが用意してるなら、使っていかないとだな。