はてなブックマーク

かったので簡単に調べた。相変わらずのチラ裏メモなのでご容赦。 まず、従来のLinuxではカーネルが立ち上がったあとにinitプロセスというのが最初に立ち上がるりこれがすべてのプロセスの親プロセスになっていろんなデーモンやらを起動させていく、というプロセス（これは単に「過程」の意）を踏んでいたらしい。そして Ubuntu 15.04以降ではこのinitプロセスにsystemdが採用されたということだ。 System Init Daemon This has changed as part of the Ubuntu 15.04 devel cycle. Ubuntu 15.04 (using Systemd by default): Systemd runs with PID 1 as /sbin/init. Upstart runs with PID 1 as /sbin/upstart.

FactoryGirlの使い方はググればすぐ出て来るんだけど、「適切」な使い方、いわゆるベストプラクティスを紹介、あるいは模索しているページは日本語ではほとんどない(英語だとちょくちょくある、たとえば「FactoryGirl slow」でググってみると良いと思う)。テストの改善を任されたのでせっかくだからその記録をここに残しておくことでFactoryGirlのより良い書き方の議論が盛り上がるようなことになればうれしいな、と思う。 アンチパターン1:とにかくcreate SQLアンチパターンみたくかっこいい二つ名をつけたかった気もするけど後で超絶恥ずかしくなるのはわかってるので、そのままの名付けをしていく。 とにかくすべてcreate、create_listを使うというパターン。本当に実際の環境をエミュレートしていることに間違いはないのだけど、とにかく遅い。IOを両方行っているし、単一のob

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

これはアプリケーションに対して、一つしかないはず。そのアプリケーション全体で必要なプロジェクトや依存関係を管理する。デフォルトでは include ':app' のみ書かれているが、これはもちろんappプロジェクト、すなわちアプリケーション本体のプロジェクトをincludeしている。たとえば外部ライブラリプロジェクトを使用する場合は、適当なディレクトリに配置したあと、そのディレクトリもincludeしなければならない。たとえばvolleyをmodules/volleyみたいな感じで引っ張ってきたとすれば、新しくincludeするために include ':app',':modules/volley' とする必要がある。プロジェクトじゃなくjarファイルをそのまま配置する場合は別に不要だと思う。あくまでビルド設定なので。 build.gradle(ルート直下) 大体一行目に書かれている英語が

Rackについて調べても、「ではまず簡単なRackアプリケーションを作ってみましょう。config.ruを開いて……」みたいな資料しか出てこなくて、サーバー側からみたRackインターフェースがどうなってるかという記事が全然見当たらなかった。んだけど、何やら外国の人のブログでちょうど望んでる内容のものがあったのでざっくり翻訳と紹介します(許可とった)。言い回しとかで解釈わかんないところがあって飛ばしたりしているので本文とニュアンスだいぶ変わってしまっているかもなのですが、まあ最低限の内容が伝われば……ご了承ください。 元記事:http://www.blrice.net/blog/2015/05/31/make-your-own-rack-server/ 自分のRackサーバーを作ってみよう Ruby触ってたら必然Rackについて学ぶよね。RailsとかSinatraとかRubyのWAFの心臓

アプリケーションはなるべく単純な方が良い。modelの中にある複雑さを新しいどこか、例えばmoduleとかクラスとかに移動することによって単純にしていくというアプローチを考えてみよう。 以下のようなオンラインショッピングアプリケーションのためのモデルを考えてみる。クラスメソッドとして、状態によってorderを検索するメソッド、手段をしてして全検索するメソッド、結果をxml,json,pdfなどのフォーマットにexportするメソッドを持っている。 # app/models/order.rb class Order < ActiveRecord::Base def self.find_purchased # ... end def self.find_waiting_for_review # ... end def self.find_waiting_for_sign_off # ... e

パターン19:読み取り可能パスワード パスワードは平文で保存するな。という話。Railsだと認証にはdeviseを使うのがデファクトスタンダードになってると思うので中でどういう扱いになってるかちょっと見てみたけど、 module Devise # Digests the password using bcrypt. def self.bcrypt(klass, password) if klass.pepper.present? password = "#{password}#{klass.pepper}" end ::BCrypt::Password.create(password, cost: klass.stretches).to_s end def password=(new_password) @password = new_password self.encrypted_pas

メモ兼ねて。あと、なかなかRailsでは生SQL書かなかったり、例がPHPだったりだったのでもうちょっと実感を掴めたらなあとか。あんまり解説とかはない。 このアンチパターン、ところどころネーミングが西尾というか鎌池くさくて面白かった。 解釈にはあんまり自信がないので、間違いは指摘していただけると嬉しいです。 パターン1:信号無視（ジェイルウォーク） @ migration file t.string hoge_ids @ Model logic fuga.hoge.ids.split.each do |hoge_id| Hoge.find(hoge_id) end

git submoduleとは git submoduleとは、一言で言うとネストされたgitレポジトリです。たとえばあるレポジトリで使用しているライブラリについて、常に最新のライブラリを使用したいという場合、そのライブラリを自分のgitリポジトリに入れてしまって更新されるたびにpullするという使い方が考えられますね。 使い方（うわべ） 既存のレポジトリの中で、 git submodule add <repository's URL> のコマンドを叩きます。イメージはcloneと一緒ですね。 該当ライブラリのver,branchを切り替えたいときは、そのディレクトリの中に入って、 git pullとかgit checkoutすればよいです。 そのあと、そこから出て、該当ディレクトリをadd,commitすればよい。 これが基本の使い方になります。かんたん！ ややこしいことがおこるとすれば

セッションについて Railsのsecret_tokenの意味がよく分かってなかったので少し調べたことのメモ。まず「セッション」という概念について。 セッションとHTTPというステートレスなプロトコル上において、一連の通信、およびそれを実現するのに必要な「状態」を記憶しておく仕組みのことだ。もうちょっと噛み砕いてみる。 よくあるたとえだけど、以下のような流れを考える。 あるショッピングサイトにアクセスする。 ↓ ログインする ↓ Ａを買い物かごに入れる ↓ Ｂを買い物かごに入れる 当然私たちの脳内文脈では、「ログインした後」に「商品をかごに入れてる」んだから何もおかしなことはないわけだけど、最初の方に書いた文章を思い出してもらうと、 HTTPというステートレスなプロトコル とある。つまり、素のままだとログイン後に送る通信の上に「私は今ログインしていますよ」、という状態情報を乗せることはでき