macbook airにarch linuxを焼いてデュアルブートする
macbookpro2016が届いてmacbook airが不要になってしまったので、売ろうとも思ったけど大した価格にもならないだろうし、おもちゃにしてみる。 手順はqiitaの記事そのまま行うので都度参照する。
デュアルブートするにはHDDのパーティション等の設定も手動で行わなくてはいけないので、まずはsierraをクリーンインストールしHDDの初期化をする。
- sierraを通常通りインストールし、
- リカバリモードで起動(
⌘ + R + 電源
) し、 - ハードディスクをフォーマットし、
- sierraの新規インストール
の手順で行う。
手元のPCではインストールに30分かかるようだったので、インストールしている間にmacbookproを使ってarch linuxのUSBローダを作った。
公式サイトより最新のISOを落とし、ddで焼く。
sudo dd if=/Users/reizist/Downloads/archlinux-2017.01.01-dual.iso of=/dev/disk2 bs=1m
なお対象USBは diskutil list
で検索し、必要であれば diskutil unmount /Volumes/<name>
しておく。
OSのインストールに時間がかかっているので途中。
低音調理器具ANOVA買った
昨今流行っている低温調理を行うベストプラクティスとして知られるANOVA(The Anova Precision Cooker)を買った。 一言で言うと水温をあげつつ撹拌してくれる物体で、今まで低温調理というとヨーグルト作成機や炊飯器を使って逐一温度を確かめる方法が主流で、各々の工夫が試されていた。 2万程度でその手間が解消されるということで、買わない手はないと話題に。
本日二度目の開封の儀です pic.twitter.com/I1MiCLrRDL
— 夜ご飯 (@reizist) 2016年12月22日
ANOVAには二種類あって、bluetoothだけでスマホ連携するやつ
お料理用 水温制御クッカー/サーキュレーター(スマホと連動して水の温度をコントロール) [並行輸入品]
- 出版社/メーカー: ANOVA
- メディア:
- この商品を含むブログを見る
と、wifiも繋げられる上位互換のやつ
がある。ちなみに2nd gen というのは最新のやつで、ワット数が800W->900Wにあがっているので多少水温を温める能力が上がっている。 とはいえANOVAは「温度調整」にステ振りしてあるので、「温度上昇」はそこまで得意ではない。 自分の場合は温めたい温度-5℃くらいまで普通にコンロで温めてからANOVAを投入し調整をする方法をとればいいかというのと、wifiで接続できることにそこまで魅力を感じなかったのでbluetoothの方を買った。
ちなみに電源部は3Pとなっていて、そのままでも使えると言われているものの電源タップなどの導入が面倒だったので
サンワサプライ 3Pプラグを2Pに変換用アダプタ トラッキング火災予防付きTAP-AD3LT
- 出版社/メーカー: サンワサプライ
- 発売日: 2003/02/01
- メディア: Personal Computers
- 購入: 3人 クリック: 18回
- この商品を含むブログ (1件) を見る
を買って2Pにして使っている。
ANOVAを買って一回目の調理としては、低温調理の代名詞・ローストビーフをやることにした。 美味しい肉の火の入れ方などはぐぐって調べるとして、一旦寝ている間の動作検証も含めて12Hやってみた。
家で肉の表面だけ155℃にするベストプラクティス知りたみ / 絶対に失敗しない肉料理のコツ!「火入れの科学」-[知識編] - Cooking Maniac https://t.co/T9hUO3KsGb
— 夜ご飯 (@reizist) 2016年12月28日
様子です pic.twitter.com/k17LJpKgph
— 夜ご飯 (@reizist) 2016年12月28日
出来上がりとしては最初はこんなものか、という感じで、手間なく今まで手動で作っていたものと同じかそれ以上の肉が作れた、程度の感情。 多分12hが長すぎたというのと、オーストラリア産の雑な肉作ったのでもう少しいい肉で試したい。 次は鶏ハムかなんか作ろうかなー
引っ越してから最高に作業が捗る
引っ越す前は自分の部屋は無くリビングに座椅子が一つあるのみで開発環境としては底辺だった。
今や一人の部屋でソファーやテーブルがあり開発したい時に開発ができて最高、良い習慣はまず環境から
apache drillが凄い
apache drillというツールが凄いので雑に使ってみました。
一言でいうと Treat your data like a table even when it's not なんですけど、もっというと jsonに対してsql実行できたりします。
公式のインストール方法の通りにできますが、
reizist@reizist ~/apache-drill-1.5.0 $ brew search apache-drill [2.3.0] apache-drill
の通りbrew経由でも落とせるみたいですね。
ちょっとサーバーのアクセスログの解析が必要だったんですけど、 気軽にやる方法ないかなーと思って(もっぱら最近はfluentd + kibanaとかBigQueryとかそこらへんが主流ですが)検討した結果、 「ltsv出力してあるnginxログをjsonに変換してapache drillに流す」ことをしてみようと思いました。 awkとか使いこなせる人にはあまり要らないのかな。
まず
gem install ltsv2json ltsv2json production_access_log.log > production_access_log.json
などとしjsonを生成したあとおもむろにapache drillを起動します
reizist@reizist ~/apache-drill-1.5.0 $ bin/drill-embedded [2.3.0] Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512M; support was removed in 8.0 3 16, 2016 8:36:58 午後 org.glassfish.jersey.server.ApplicationHandler initialize 情報: Initiating Jersey application, version Jersey: 2.8 2014-04-29 01:25:26... apache drill 1.5.0 "a drill is a terrible thing to waste" 0: jdbc:drill:zk=local> select * from dfs.`/tmp/production_lb_access.json` where uri='/'; +-----------------------------+-----------------+---------------+-------+---------+------+---------+-------+--------------------------+----------------------------------------------------------------------------------------------------------------+----------+--------+-----------+----------+--------------------+ | time | host | forwardedfor | user | method | uri | status | size | referer | ua | reqtime | cache | runtime | apptime | vhost | +-----------------------------+-----------------+---------------+-------+---------+------+---------+-------+--------------------------+----------------------------------------------------------------------------------------------------------------+----------+--------+-----------+----------+--------------------+ | 14/Mar/2016:05:42:24 +0900 | 111.11.11.111 | - | - | GET | / | 302 | 96 | - | Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36 | 0.110 | - | 0.107515 | 0.110 | [censored] | | 14/Mar/2016:06:02:17 +0900 | 111.11.11.111 | - | - | GET | / | 302 | 96 | - | Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) | 0.011 | - | 0.008270 | 0.011 | [censored] | | 14/Mar/2016:06:47:02 +0900 | 111.11.11.111 | - | - | GET | / | 302 | 194 | - | Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12F70 | 0.055 | - | 0.051819 | 0.055 | [censored] | +-----------------------------+-----------------+---------------+-------+---------+------+---------+-------+--------------------------+----------------------------------------------------------------------------------------------------------------+----------+--------+-----------+----------+--------------------+
おぉ凄い便利。
例えば実アクセスログから処理時間がかかっているリクエストを調べたい場合は以下のようにできますね。
0: jdbc:drill:zk=local> select * from dfs.`/tmp/production_lb_access.json` order by runtime desc limit 10; +----------+--------+---------------+------------------+---------+----------+----------+-----------+-------+---------+-----------------------------+----------------------------------------------------------------------------------------------------------------+------------------------+-------+------------------+ | apptime | cache | forwardedfor | host | method | referer | reqtime | runtime | size | status | time | ua | uri | user | vhost | +----------+--------+---------------+------------------+---------+----------+----------+-----------+-------+---------+-----------------------------+----------------------------------------------------------------------------------------------------------------+------------------------+-------+------------------+ | 9.935 | - | - | 111.111.11.11 | POST | - | 9.979 | 9.932773 | 5666 | 200 | 14/Mar/2016:05:12:42 +0900 | Dalvik/1.6.0 (Linux; U; Android 4.4.4; 305SH Build/S0114) | /path/action | - | [censored] | | 9.914 | - | - | 111.111.11.11 | POST | - | 9.963 | 9.911458 | 9185 | 200 | 14/Mar/2016:12:34:58 +0900 | Dalvik/1.6.0 (Linux; U; Android 4.4.2; F-01F Build/V10R22A) | /path/action | - | [censored] | | 10.472 | - | - | 111.111.11.11 | GET | - | 10.472 | 9.910428 | 3611 | 200 | 14/Mar/2016:14:14:02 +0900 | Mozilla/5.0 (iPhone; CPU iPhone OS 9_2_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13D15 | /path/action | - | [censored] | | 9.901 | - | - | 111.111.11.11 | POST | - | 9.901 | 9.897920 | 8154 | 200 | 14/Mar/2016:14:13:03 +0900 | Dalvik/2.1.0 (Linux; U; Android 5.0.2; SC-05G Build/LRX22G) | /path/action | - | [censored] | | 14.933 | - | - | 111.111.11.11 | POST | - | 14.956 | 9.888321 | 3377 | 200 | 14/Mar/2016:14:39:21 +0900 | Dalvik/1.6.0 (Linux; U; Android 4.4.2; LGV31 Build/KVT49L.LGV3110f) | /path/action | - | [censored] | | 9.884 | - | - | 111.111.11.11 | POST | - | 9.884 | 9.881206 | 5225 | 200 | 14/Mar/2016:13:19:43 +0900 | hoge/1.0.10 CFNetwork/758.2.8 Darwin/15.0.0 | /path/action | - | [censored] | | 9.910 | - | - | 111.111.11.11 | POST | - | 9.910 | 9.869544 | 4398 | 200 | 14/Mar/2016:03:35:00 +0900 | Dalvik/1.6.0 (Linux; U; Android 4.1.2; SBM203SH Build/S0026) | /path/action | - | [censored] | | 10.186 | - | - | 111.111.11.11 | POST | - | 10.215 | 9.869021 | 4168 | 200 | 14/Mar/2016:03:40:30 +0900 | hoge/1.0.10 CFNetwork/758.2.8 Darwin/15.0.0 | /path/action | - | [censored] | | 9.862 | - | - | 111.111.11.11 | POST | - | 9.862 | 9.859476 | 2938 | 200 | 14/Mar/2016:12:30:27 +0900 | Dalvik/2.1.0 (Linux; U; Android 5.1; KYV35 Build/103.0.2e00) | /path/action | - | [censored] | | 9.851 | - | - | 111.111.11.11 | POST | - | 9.871 | 9.847916 | 8592 | 200 | 14/Mar/2016:05:11:59 +0900 | Dalvik/2.1.0 (Linux; U; Android 5.1; KYT31 Build/100.0.1c10) | /path/action | - | [censored] | +----------+--------+---------------+------------------+---------+----------+----------+-----------+-------+---------+-----------------------------+----------------------------------------------------------------------------------------------------------------+------------------------+-------+------------------+
ちなみに上記クエリは3GBのjsonファイルに対して実行しかかった時間は 74.361 seconds
でした。
上記程度であれば例えばNewRelicのようなものがあればこんなことをせずにすみますが、使い慣れたSQLでさらさらと手元で調べられるのは小回りがきいていいですね。
rails+unicornで特定のサーバーだけ異なる設定でunicornを起動する
production環境においてappサーバーと管理画面を同居させていた場合、unicornやnginxの設定を同一のものにしなくてはいけない制限が生まれてしまう。
今携わっているプロジェクトで、通常のappサーバーでタイムアウトを30秒に設定しているため管理画面から行う特別重い処理がタイムアウトが発生して満足に使えない状況が発生した。
このため管理画面を別サーバーに切り出す対応を行ったが、unicornの設定に少しだけ手こずったのでメモ。
task :set_unicorn_config_path do roles(:admin) do |host| set :unicorn_config_path, -> { File.join(current_path, "config", "unicorn", "admin.rb") }' end end before 'unicorn:start', :set_unicorn_config_path
対応内容は上記のみなのだけど、 capistrano3_unicorn
の unicorn.rake
における unicorn:start
にフックしてproductionのみ set_unicorn_config_path
タスクを実行するようにした。 role :admin
に指定したインスタンスは、別のunicornの設定ファイルをつかうことができる。
unicorn:restartからもinvokeされるので、結果 deploy:restart
からでも実行され、
cap deploy
でも cap unicorn:restart
でも上記タスクは実行される。助かる。
The theory of everythingを観た
職場の人にオススメを聞いてこの映画を観た。 残念ながら日本語に疎いので的確な表現が思いつかずにいる。
とりわけ評価するべき点としては、 主演のエディ・レッドメインとフェリシティ・ジョーンズの演技が映画の世界観に入り込むのに最大限の手助けをしてくれた。
個人的にはもう少し宇宙理論の話を掘り下げて欲しかった。原題の「The theory of everything」が「博士と彼女のセオリー」と訳される程度にはヒューマンドラマ、とりわけ「愛」にフォーカスした映画だ、という事前情報を得てから観ればそうは思わなかったのかもしれない。 演出も綺麗で、名作映画を見終わった後特有の余韻感を感じることができたので、ともすれば自分の中では「名作映画」のリストに入るのだろうな。
migration comment gemを使っていたらtableのROW_FORMATがCompactになって困った
何があった
my.cnf
にてinnodb_large_prefix = ON, innodb_file_format = Barracuda
であるのにvarchar(255)
カラムに対する unique index付与時Specified key was too long; max key length is 767 bytes
で怒られるinnodb_large_prefix = ON
なのにlarge_prefix
が有効にならないということは、ROW_FORMAT=DYNAMIC
でないとアタリをつけ検証したところ、確かにDYNAMIC
でなくCompact
になっていることが判明- 同migrationファイルを用いてstaging環境で実行すると、意図通りmigrationは実行されindexも付与される。
詳細
絵文字対応を行うためutf8でなく1文字4byteのutf8mb4エンコードでDB運用を行う場合、767byteまでしかindex column lengthを許容していないmysqlの仕様上varchar(255)のカラムに普通にindexを貼ることは出来ない。これに対応するためには、
- mysqlの設定で
innodb_large_prefix
を有効に - tableの設定で
ROW_FORMAT=DYNAMIC or COMPRESSED
に
する必要がある。 参考
このうち後者に関しては
ActiveSupport.on_load :active_record do module ActiveRecord::ConnectionAdapters class AbstractMysqlAdapter # utf8mb4 を使用するため index のサイズを拡大したい。 # そのために必要な設定です。 # @see config/database.yml def create_table_with_innodb_row_format(table_name, options = {}) table_options = options.reverse_merge(options: 'ENGINE=InnoDB ROW_FORMAT=DYNAMIC') create_table_without_innodb_row_format(table_name, table_options) do |td| yield td if block_given? end end alias_method_chain :create_table, :innodb_row_format end end end
のようにモンキーパッチを当てて対応を行っている。
だが、ローカル環境においてのみ上記のモンキーパッチによって付与されるはずの ROW_FORMAT=DYNAMIC
が正しく有効にならず、作られるテーブルは Compact
になっていることを発見した。
デバッグしたところ、何故かローカルではモンキーパッチ部分の引数にデフォルト値のようなものが渡されてしまい、意図せぬ挙動になってしまっていた。
development環境とstaging環境において挙動が変わる→development環境にのみ使用しているgemが怪しいとアタリをつけ調査を開始した。
調査
staging環境におけるデバッグ
From: ***/server/config/initializers/model_ext.rb @ line 193 ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format: 191: def create_table_with_innodb_row_format(table_name, options = {}) 192: binding.pry => 193: table_options = options.reverse_merge(options: 'ENGINE=InnoDB ROW_FORMAT=DYNAMIC') 194: create_table_without_innodb_row_format(table_name, table_options) do |td| 195: yield td if block_given? 196: end 197: end 2.1.5 (#<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x007fe2a9ae94d8>):0 > show-stack when_started hook failed: NoMethodError: private method `eval' called for nil:NilClass ***/server/vendor/bundle/ruby/2.1.0/gems/pry-stack_explorer-0.4.9.1/lib/pry-stack_explorer.rb:109:in `bindings_equal?' (see _pry_.hooks.errors to debug) Showing all accessible frames in stack (34 in total): -- => #0 create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #1 [block] block in run <Byebug::PryProcessor#run(&_block)> #2 [method] run <Byebug::PryProcessor#run(&_block)> #3 [method] resume_pry <Byebug::PryProcessor#resume_pry()> #4 [method] at_line <Byebug::PryProcessor#at_line()> #5 [method] at_line <Byebug::Context#at_line()> #6 [method] create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #7 [method] create_table <ActiveRecord::SchemaMigration.create_table(limit=?)> #8 [method] initialize_schema_migrations_table <ActiveRecord::ConnectionAdapters::Mysql2Adapter#initialize_schema_migrations_table()> #9 [method] initialize <ActiveRecord::Migrator#initialize(direction, migrations, target_version=?)> #10 [method] up <ActiveRecord::Migrator.up(migrations_paths, target_version=?)> #11 [method] migrate <ActiveRecord::Migrator.migrate(migrations_paths, target_version=?, &block)> ....
development環境におけるデバッグ
2.1.5 (#<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x007fee429f8cc8>):0 > show-stack when_started hook failed: NoMethodError: private method `eval' called for nil:NilClass ***/server/vendor/bundle/ruby/2.1.0/gems/pry-stack_explorer-0.4.9.1/lib/pry-stack_explorer.rb:109:in `bindings_equal?' (see _pry_.hooks.errors to debug) Showing all accessible frames in stack (36 in total): -- => #0 create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #1 [block] block in run <Byebug::PryProcessor#run(&_block)> #2 [method] run <Byebug::PryProcessor#run(&_block)> #3 [method] resume_pry <Byebug::PryProcessor#resume_pry()> #4 [method] at_line <Byebug::PryProcessor#at_line()> #5 [method] at_line <Byebug::Context#at_line()> #6 [method] create_table_with_innodb_row_format <ActiveRecord::ConnectionAdapters::AbstractMysqlAdapter#create_table_with_innodb_row_format(table_name, options=?)> #7 [method] create_table <ActiveRecord::ConnectionAdapters::Mysql2Adapter#create_table_without_migration_comments(table_name, options=?)> #8 [method] create_table_with_migration_comments <MigrationComments::ActiveRecord::ConnectionAdapters::MysqlAdapter#create_table_with_migration_comments(table_name, options=?)> #9 [method] create_table <ActiveRecord::SchemaMigration.create_table(limit=?)>
#7
においてstgには無かった処理が介入しているのを発見。
2.1.5 (#<ActiveRecord::ConnectionAdapters::Mysql2Adapter:0x007fc938689b70>):0 > frame 7 Frame number: 7/35 Frame type: method From: ***/server/vendor/bundle/ruby/2.1.0/gems/activerecord-4.0.8/lib/active_record/connection_adapters/abstract_mysql_adapter.rb @ line 471 ActiveRecord::ConnectionAdapters::Mysql2Adapter#create_table_without_migration_comments: 470: def create_table(table_name, options = {}) #:nodoc: => 471: super(table_name, options.reverse_merge(:options => "ENGINE=InnoDB")) 472: end
migration comment gem をロードした結果、ActiveRecord::ConnectionAdapters::Mysql2Adapter::AbstractMysqlAdapter#create_table
により下記メソッドの引数 options
に常時 { options: 'ENGINE=InnoDB' }
という値がわたってしまったことが原因。
def create_table_with_innodb_row_format(table_name, options = {}) table_options = options.reverse_merge(options: 'ENGINE=InnoDB ROW_FORMAT=DYNAMIC') create_table_without_innodb_row_format(table_name, table_options) do |td| yield td if block_given? end end
hash_a.reverse_merge(hash_b)
は hash_a
の値を優先するため ROW_FORMAT=DYNAMIC
が反映されなかった。
とはいえ、幸いなことに varchar(192) 以上必要なカラムは現プロジェクトに存在しないので、
migration commentのgemを使いindex使用時は limit: 191
をつける対応で乗りきれるので、問題は無かった。