2015-05-28

あなたとFacebook、今すぐサブミッション

Facebook

Facebook Graph API 2.0に完全に切り替わって1ヶ月が経とうとしている。

Facebookのフィードに投稿するには、publish_actionsというパーミッションが必要なのだが、切り替わりに際し、パーミッションを聞くためにFacebookへのレビューが必須になった。つまりレビューが通らなければ、そもそもユーザにパーミッションを求められないという話だ。で、そのレビューを通して、知見を得たので残しておく。

やること

今回、ガイドラインやドキュメント、FAQを読みながらやったことは以下のような感じ。はっきり言って大量にありすぎて、日本語訳作ってもすぐ腐ると思うので、原文を参照するのが好ましい思った。

Facebookの定めるガイドラインを読む（必要になるタイミングでパーミッションダイアログを出すとかPrefillをするなとかタグ付けするユーザを簡単に選択・削除できるようにしろとかある）
ガイドラインを守って実装する
レビューの手順は明確にスクリーションショットを使いながら、どんなアクションを使うのかということまで説明する（書き方のヘルプリンクがあるので参考にする）
レビューの際、レビュアーは自前でいくつかテストアカウントを持っているので、テストユーザ（オプションの項目）でテストして欲しければ、明記する

レビューの環境

いくつか方法があって、一番良さそうなのはTest Appを使うこと。昔はTest Appという機能がなく、テスト用に単独のFacebookアプリを作ってテスト環境を作っていたが、それが本番に紐づく形で用意できるようになったので、それを使ってテスト環境を作り、それをレビューしてもらえばいいかもしれない。僕のケースではテストユーザの場合のみ、機能を解放するような仕組みを作って、それでレビューしてもらったので、上記の方法でやる機会があって成功したら教えて欲しい。

起こったこと

2回ぐらいリジェクトされた。そして毎回同じメッセージで、どこを直していいのか分からない。

f:id:terut:20150528230202p:plain

ヘルプを見ると、例えばログインできないなどの理由でレビューができなかったといった場合に返される結果らしい。だがしかし、ログインできているし、管理者権限であればレビューがいらないので、機能を使えている。

で、どこか違反してたらもう少し詳しい結果が返ってくるはずなので、レビューすらされていないと考え、ひたすらレビューのための手順を詳しく用意し、スクリーンショットを追加した。さらに3回ほどレビューに出したけど、リジェクトされて絶望しかない。

とにかく全く意味不明で、ドキュメントを読み直しても、手の打ちようがなかった。

ちなみにコンタクト用のボタンが用意されてはいるが、どうも広告出したりしないと使えないとのこと。これに関しては僕は聞いただけなので、よく分からない。

結果

Facebook上にはFacebook Developer CommunityというFacebook Groupが存在していて、その中には中の人がいることが分かった。 Facebookのドキュメントにはそこに尋ねてみろとの勧めがあったので、尋ねることにした。

投稿すると中の人からレスがあった。

やあ xxx, 君たちのように間違った 'general issues' メッセージでリジェクトされてるアプリがいくつかあって、Fixするために動いてるから解決したら君に連絡するよ。（超意訳）

超ウケない。

その後、数時間して直したからダッシュボード見てくれって言われたらレビュー通ってた。

教訓

Facebookでの問題はFacebook Development GroupというFacebook Groupに入って聞くのが良い。

タイトルはあなたとJava、いますぐダウンロードに強い影響を受けた結果です。

2015-05-01

続・Arch Linux曰く、Something has gone wrong

先日、Arch Linux曰く、Something has gone wrong - 解せぬ日記でArch Linuxがぶっ壊れた話をしたんだけど、またぶっ壊れた。

原因はやはりnvidiaの349.16-1のパッケージ群っぽい。

よかろう、ならばダウングレードだと思ったんだけど、今回は詰んでいた。

なぜなら他にもアップグレードが来ていて、全部一緒にアップグレードした結果、linux-4.0系が入り、nvidiaの346.59-1はlinux-3.20以下という依存関係を持っていたためだ。

nvidia-349.16-2が来てたもんで、直ってんじゃないのとノリで上げてしまった。

ということで、本格的に格闘することにした。

対処法

ログの見方などは前回、説明した通りにやればよい。

で、今回はちょっと詳細にArch Linuxの公式のBBSやバグトラッカーなどを読んでいった。

すると、microcodeのアップデートする必要がありそうなことが分かった。

https://bbs.archlinux.org/viewtopic.php?pid=1522487#p1522487

理由は以下の通り。

https://bbs.archlinux.org/viewtopic.php?pid=1522675#p1522675

読むのが面倒くさい人のために簡単にまとめると、nvidia-libglの496.16-1にHLEの命令セットが導入されたためで、microcodeのアップデートによってHLEの命令セットを無効化することができるという感じだった。

CPUはHaswellを使ってて、Intel TSXはHLEのインターフェースを提供するらしいが、命令自体はエラッタのため、無効化されたとのことだった。

北森瓦版 - “Haswell”のTSX命令にエラッタが発見され、無効化される処置がとられる

無効化はmicrocodeによって行われたりするみたいで、BIOSのアップデートなどで提供されるらしいのだけど、Linuxなどではブート後にアップデートする仕組みを用意してるらしい。

ただ、あるバージョン以降、自動でアップデートしなくなったので、自分でパッケージを入れる必要がありそうだった。

とまあ、色々調べては見たものの、正直、練度が足りなすぎてホエーってなってる。

あくまで推測にすぎないとのことだが、fixしたよーとの報告も多々あったので、実際に試してみた。

作業ログ

前回の話でLive USBなどが必要という話はしたので、Live USBをブートしたところからやっていく。今回はintel-ucodeというパッケージをインストールするのだけど、/boot/intel-ucode.imgができるのでbootもマウントしておく。

ここを見ながらやるとよい。

Microcode - ArchWiki

日本語WikiはGrubの設定の部分が古くて、コードや上記Wikiを見ると最新版のGrubではintel-ucodeの対応はすでに入っているため、インストールしたらgrub-mkconfigを実行すればよくなってる。

root@arch$ mount /dev/sda6 /mnt
root@arch$ mount /dev/sda5 /mnt/boot
root@arch$ mount /dev/sda2 /mnt/boot/efi
root@arch$ arch-root /mnt

sh-4.3$ export LANG=en_US.UTF-8
sh-4.3$ pacman -Ss intel-ucode
sh-4.3$ grub-mkconfig -o /boot/grub/grub.cfg

あとはこれで再起動すれば無事にエラーは解消して、いつもの画面に会える。

まとめ

Arch Linuxは相変わらずkawaii。

nvidiaのパッケージが対応しない限り、nvidiaのパッケージはアップデートできず、アップデートが億劫になるので、対応したほうがよいように思う。

あとCPUのこととか、Linuxのこととか知らなすぎて辛い。

2015-04-24

Arch Linux曰く、Something has gone wrong

Arch Linux

Arch Linuxはローリングリリースを採用しているので、カジュアルにガンガン、パッケージのアップデートが来る。常に最新のものが提供され、最新こそ安定ぐらいの勢いを感じるわけだけど、たまーにぶっ壊れる。

そして今日もぶっ壊れた。

Archぶっ壊れて爆笑してる pic.twitter.com/N6NNyHMonP
— レベルがあまりに低い (@terut) April 23, 2015

体感では壊れることは滅多にないし、ググッて解決方法が見つからない、またはArch Linuxのオフィシャルなサイトにバグ情報が上がってないことは、もっとない。

が、今日は見当たらなかったので、そんな時どうするかというのを残しておく。

必要となるもの

壊れた時のために、Arch LinuxのLive USBなどが必要。OSが入っているパーティションをマウントして原因を探るために、用意しておいたほうがいいと思う。

対処法

まずはLive USBを挿し、UEFIの設定画面からLive USBを起動する。

起動したら、OSが入ってるパーティションをマウントし、Arch用のコマンドでchrootする。

root@arch$ mount /dev/sda6 /mnt
root@arch$ arch-chroot /mnt

sh-3.2$
# LANG=ja_JP.UTF-8だと化けてメッセージが見れない
sh-3.2$ export LANG=en_US.UTF-8

これで、普段使っているOSのログなどが見れるようになるので、ログを眺める。

# -b はブート時のログを見るもので、-1をつけると1回前のログが見れる
$ journalctl -b -1

眺めてると、NVIDIAのロードのあたりでコケてそうな雰囲気だったので、壊れる前にアップグレードしたNVIDIA関連のパッケージが悪さをしてるんだろうと当たりをつけた。

ということで、アップグレードしたパッケージをダウングレードする。

公式Wikiでは推奨していないし、依存を壊さないよう細心の注意を払う必要がある。またダウングレードする前に、バグ報告にちょっとでも時間を割いてくれるとうれしそうな雰囲気だった。

# 更新したパッケージを確認する
$ ls -lat /var/cache/pacman/pkg/ | head -10

# cacheから依存関係があるものをすべてダウングレード
$ pacman -U /var/cache/pacman/pkg/nvidia-346.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-utils-346.59-1-x86_64.pkg.tar.xz /var/cache/pacman/pkg/nvidia-libgl-346.59-1-x86_64.pkg.tar.xz

今回はNVIDIAの349.16-1のパッケージが悪さをしていたようで、ダウングレードした結果、無事起動するようになった。

まとめ

同じような現象が起きた人の参考になれば最高。

Arch Linuxかわいいよ、Arch Linux。

2015-01-07

MacOSX（Yosemite）でシステム終了をフックする

MacOSX

Mac OSXのログアウトのフックを実現したくて、launchdを使ってbashのプロセス常駐させてtrapしたけど、blockせずにログアウトしていった。非常に味わい深い。

LoginHook、LogoutHookを使ってscript走らせればいいじゃんってドキュメントはいっぱい見つかるんだけど、2014年の9月頃にはすでにdeprecatedだって言われてて、Launch Daemons、Launch Agentsを使ってくれよなってAppleのドキュメントは言ってる。

Daemons and Services Programming Guide: Customizing Login and Logout

ただ、最初に言ったようにblockせずにソッ閉じされる。

解決方法

AppleScriptは実は簡単にApplicationにできる。普通にdialogとか出すだけでも可能っぽい。 AppleScript Editorでnotification出すコードを書いて保存時にFile FormatをApplicationにすればいい。

そこで、AppleScriptでApplicationを作って、StartupItemsに登録して、常駐させることにした。ログアウト時にはApplictionの終了イベントが来るはずで、夜フクロウとか使ってる人は分かると思うけど、終了時にダイアログが出てログアウトをblockする。なので、Applicationに終了イベントをフックする処理をAppleScriptで書いて、ダイアログを出すようにした。

on quit
  display dialog "退勤すんの？" buttons {"Yes", "Not yet"} default button "Not yet"

  if button returned of result is "Yes" then
    --change next row.
    do shell script "/usr/bin/say goodbye"
    continue quit
  else if button returned of result is "Not yet" then
    continue quit
  end if
end quit

アプリを作ってgithubに上げといたから、使いたければ使ってください。アプリ自体は2014年の9月頃に作ったものだけど、Yosemiteでも問題なく動いてるぞい。

https://github.com/terut/logouthook

2014-12-19

Rubyのモジュールでextend self

Ruby

冷静になってゆっくり理解すれば、そりゃそっかという話なんだけど、Railsプロジェクトのコードでめっちゃ混乱したので、書いておく。

TL;DR

extend selfは特異クラスへのincludeと等価というのがミソ。

混乱したコード

目にした瞬間これ本当に大丈夫なのかと思ったコード。

class ApplicationController < ActionController::Base
  # something

  class << ActionController::HttpAuthentication::Digest
    # seconds_to_timeoutを書き換えたい
    def validate_nonce(secret_key, request, value, seconds_to_timeout=60*60)
      # somthing
      super
    end
  end
end

このコードを見て、いやいやそりゃ大丈夫でしょと思う人はそっとタブを閉じるといい。

僕はというとあれ、superってどういうこと？ってなった。 Digestの特異クラス定義式を使って特異クラスにメソッドを追加しているのだけど、superをcallしてもメソッドが見つからず探索は終了しないかという疑問だ。つまり、メソッドは上書きされるはずではないかと思った。

ただこのコード、こいつ動くぞ！って驚きと共に動いていた。

そこでDigestの定義を見てみる。そうすると、モジュール自身に対してextend selfで定義してあった。

module ActionController
  module HttpAuthentication
    module Digest
      extend self

      # somthing

      def validate_nonce(secret_key, request, value, seconds_to_timeout=5*60)
        # something
      end
    end
  end
end

それでもなぜメソッドが上書きされないのかとか思っていたが、冒頭に書いたとおり、このモジュール自身に対してのextend selfが今回のミソで、これにより上書きされないようになる。より理解を深めるために、簡略化したコードで考える。

簡略化したコード

上記で説明したコードの周りを調べて簡略化すると次のようになる。 AがActionController::HttpAuthentication::DigestでHogeがApplicationController、hogeがvalidate_nonceといった感じ。

module A
  extend self

  def hoge
    puts "A" 
  end 
end

class Base
  def call
    A.hoge
  end 
end

class Test < Base
  class << A
    def hoge
      puts "test"
      super
    end 
  end 
end

Test.new.call

実行すると次のような結果だ。

$ ruby test.rb
test
A

superによりちゃんとメソッドがcallされていることが分かる。これを理解するために書き換えをしてみる。

module A
  #extend self

  class << self
     include A
  end

  def hoge
    puts "A" 
  end 
end

class Base
  def call
    A.hoge
  end 
end

class Test < Base
  class << A
    def hoge
      puts "test"
      super
    end 
  end 
end

Test.new.call

$ ruby test.rb
test
A

これを見ると謎が解ける。特異クラス定義式で定義されたhoge メソッドとモジュールのincludeによって定義されたhoge メソッドという関係なので、特異クラス定義式のhoge メソッドが先に呼ばれ、あとからモジュールで定義されたhoge メソッドが呼ばれるというわけだ。

モジュールのincludeに関してはメタプログラミング Rubyとか見ながら、自分で試してみるとモジュールのincludeによってモジュールが継承チェーンに挿入されていることが分かると思う。

まとめ

extend selfは怖くない。

includeうんぬんの辺りがわからない人はメタプログラミング Rubyを読みましょう！

メタプログラミングRuby

作者: Paolo Perrotta,角征典
出版社/メーカー: アスキー・メディアワークス
発売日: 2010/08/28
メディア: 大型本
購入: 18人クリック: 533回
この商品を含むブログ (125件) を見る

2014-12-15

MySQL Casual Talks vol.7 に行ってきた

MySQL ブログ

久しぶりに MySQL Casual Talks vol.7 に行ってきた。

カジュアル〜とか言ってヘラヘラしてたらワンパンで吹っ飛んだ。相変わらずのガチュアルだった。

気になったトーク

面白いなーと思ったのは継続的リストアの話で、僕にはあまりそういう観点がなくて、よくよく考えると、正しくバックアップが取れて、リストアが正しくできるというのは非常に重要だと思う。日頃から正しくリストアができることを証明しておくと安心感が高まる。普通にバックアップ取って、ヘラヘラしてたらいざという時、詰む。

<a href="http://kakerukaeru.hatenablog.com/entry/2014/12/13/213342">MySQL Casual Talks vol.7で「Continuous Restoreへの道」を発表奴 - たまごかける日報</a>

相変わらずかみぽさんがすごかった。 RailsのMySQL周りに怒涛のプルリクエストを投げまくってるらしいけど、なかなかマージされないので、gemにバックポートしたとのことだった。 RailsのMySQL周りのプルリクエストは放置される傾向にあるっぽい。

<a href="http://qiita.com/kamipo/items/11b55caf329210923a9a">activerecord-mysql-awesome - ActiveRecordのMySQL向けパッチのバックポート集 - Qiita</a>

ペパボの新人さんがパワハラにあって、MySQL 4.0からバージョンアップした話は最高にグレートだった。 MySQL 4.0.25から5.0.96だったみたいだけど、レプリケーションでなんとかしたっぽい。 gccとの相性の問題とか既存のスレーブとかすごい色んな問題を抱えながらもバージョアップを成し遂げたのは、本当にすごいと思う。新人さんにそういう仕事を任せるペパボもまたよいと思った。薄い本にしたら売れそう。

MySQL 4.0で9年動き続けたサーバをリプレイスしてバージョンアップした話 from Takahiro Okumura

MySQL Fabricのデモを見て、カジュアルに切り替わってて未来を感じた。辛そう。

<a href="http://qiita.com/advent-calendar/2014/mysql_fabric">MySQL Fabricつらい Advent Calendar 2014 - Qiita</a>

まとめ

発表者の方、主催関係者の方、本当にありがとうございました。お疲れ様でした。最高の夜でした。

2014-12-02

PipelightでSliverlightに打ち勝つ

Arch Linux

Arch LinuxでLinux生活していると、開発するのに便利最高だし、他のことも大概できるのだけど、GyaoとかDMMとかDMMとかDMMを見ることができない。これはDRMが関係していて、Silverlightのインストールが必要になってる。

TL;DR

PipelightでSilverlightに挑んだ結果、ワンパンで吹っ飛んだ。

Pipelight

LinuxだとMoonlightとかってSliverlightのオープンソース実装があるのだけど、僕の環境であまりうまく動かなかった。そこでPipelightというwineを使ってLinuxのブラウザ上でwindowsのブラウザのプラグインを使えるようにするラッパーツールがあるので、使ってみた。

NPAPIを使っているのでChrome/Chromiumの35より上のバージョンでは動かないらしい。 NPAPIのサポートを切ったからで、PPAPIを使おうとしたけど、以前と同じやり方ではうまく動かず、またバグも出てしまったとのことだった。どうしてもChromeを使いたければ、NPAPIのパッチを当てるか、バージョンを下げて使わないといけないっぽい。

Firefoxを使うのが楽そう。

インストール

インストールの方法はいくつかある。 Arch LinuxのWikiではAURからインストールすることが、メインで書いてあるが、本家サイトの推奨はpacmanへリポジトリを追加して、バイナリをインストールすることだ。

Pipelight | Installation - Arch Linux

wineのコンパイルとインストールはめちゃめちゃ時間かかるので、僕もリポジトリの追加方式をすすめる。あとmultilibがいっぱい入ったりするので、ちょっとウッとなる。

使い方

インストールが終わったらあとはUserAgentを変えるだけ。ドキュメントを読む限りはIEとかのUAにせずFirefoxだったらWindowsのFirefoxにするのがよさそう。だいぶ雑な説明だけど、IEだとActiveXとか色々あるとのこと。

Firefoxのアドオンだと、User Agent Overriderがいいらしい。 User Agent Switcherは問題が起こるって書いてあった。

Pipelight | Installation - User Agent

Firefoxを起動するとwineの某が一緒に起動するから入ったことが分かると思う。

まとめ

こんなに色々なドキュメントを読み、インストールを頑張った結果、めちゃめちゃ高まった気持ちを抑えきれずにDMMのサンプルを試しに見に行ったらエラーが出た。エラー見る限り、DRM周りでコケてるのかなーと思ったけど、ダメージがでかすぎたので、あまり調べずにそっとアンインストールした。

最高。