読者です 読者をやめる 読者になる 読者になる

解せぬ日記

雑な話をする

MF Geeks Nightに行ってきた

f:id:terut:20150626001820j:plain

TL;DR

プロダクトを作る上での文化が醸成されつつある雰囲気を感じつつも、自分で色々やっていけそうな余地もあり、楽しそうな職場だったんでオススメだと思う。興味ある人はぜひマネーフォワードに遊びに行ってみるとよさそう。

事の始まり

@ppworksさんがエスパーになった結果、MF Geeks Nightというのがあるからどう?みたいな話をもらった。以前から開催されていたようで、ブログにも様子が上がってる。

moneyforward.com

毎回ゲストを呼んで開催しているとのことで、他の会社の勉強会に参加するのは結構新鮮だった。

やったこと

毎回、面白くなるように色々考えられているようで、今回は社内の各チームの開発環境や開発フロー、取り組んでいることについて発表するスタイルだった。すごく色んな取り組みを自発的にやっているようで、各チームがよりよい開発を目指してたのが印象的だった。

一応外部の人間に言ってた内容なので、公開してもよい情報だろうけど、ハッシュタグなどはなかったんで、内容については触れない。

まとめ

とにかくマネーフォワード各位に勢いがあって、最終的に入社だぁ〜みたいな奇声を発するようになっていた。奇行種かな?

何が起こったのか分からなかったけど、とにかく勢いがある(大事なことなので2回ry)上に技術の話もできて最高〜。

僕はぼっち力がだいぶ高いので、ぼっちになるかな〜と思ってたんだけどppさんに色々配慮していただいて、エンジニアの方を紹介してもらったりして楽しく過ごせた。感謝しかない!

systemd-tty-ask-password-agentの使い方

TL;DR

Please enter password with the systemd-tty-ask-password-agent tool!と言われたら、別のパネルなりウィンドウなり開いて、systemd-tty-ask-password-agent --queryを実行すれば良い。

systemd-tty-ask-password-agentの使い方

Arch LinuxはSystemdを採用してて、Systemdを使ってOpenVPNとかでVPN接続するときに以下のようなメッセージが表示されることがある。

$ systemctl start openvpn@client

Password entry required for 'Enter Private Key Password:' (PID 6145).
Please enter password with the systemd-tty-ask-password-agent tool!

メッセージにはsystemd-tty-ask-password-agentを使ってパスワードを入れてねと書いてあるわけだけど、ノリでそのままパスワード入力するとパスワードがまんま表示され、タイムアウトの後に次のインプットとして入力され、実行される。

どうやってパスワードを入力すんだぜ?と思ってたら見つけた。

issue with Vpn HideMyAss / Newbie Corner / Arch Linux Forums

別のターミナル開いて実行するといいよとのこと。

$ sudo systemd-tty-ask-password-agent --query
[sudo] password for terut: 
Enter Private Key Password: ****************

入力するとこんな感じでパスフレーズが聞かれて、接続が確立した。

ちなみにもっとよいやり方がないかとドキュメントを見てみたけど、systemd-tty-ask-password-agentはこういった使い方をするものっぽい。

Ubuntu Manpage: systemd-tty-ask-password-agent - List or process pending systemd

プロセスを見ていると/usr/bin/systemd-tty-ask-password-agent --wallというのがあったんで、こいつがフォワードしてメッセージを出してるってことなのかな。

あとOpenVPNには--askpass [file]ってコマンドライン引数があってファイルにパスワードを書いてもよさそうだったけど、嫌だったので却下した。

ちなみにOpenVPNのSystemdのUnitはリスト表示するとopenvpn@.serviceってなってるんだけど、これはUnitファイルの中で引数を受け取るためで、起動はリストで表示されたものではなく、@のあとに引数を与えて起動することになる。

# systemctl start openvpn@[設定ファイル名]のような感じで、もしclient.confを読むなら
$ systemctl start openvpn@client

コマンドラインからVPN接続最高〜。

Arch LinuxでSkypeがクラッシュする

Skypeがクラッシュして全く開けなくなった。一瞬ウィンドウが開いて、すぐ閉じる感じ。

すでにバグ報告は上がっていた。

FS#45204 : [lib32-qt4] [skype] Skype immediately crashes after launch

lib32-qt4をlib32-qt4-4.8.7-1からlib32-qt4-4.8.6-4へダウングレードすればいいらしい。

$ sudo pacman -U /var/cache/pacman/pkg/lib32-qt4-4.8.6-4-x86_64.pkg.tar.xz

Arch Linuxかわいい。

追記 2015/06/06 23:00

lib32-qt4-4.8.7-2がマッハで来たので、直った。

KeePassXのデータベースがコンフリクトした話

僕はパスワード管理にKeePassXを使ってる。

そのデータベースファイルがコンフリクトするという地獄みたいなことが起きた。

f:id:terut:20150605104240p:plain

経緯

Dropbox*.kdbファイルを同期して、Win/Mac/Linuxで参照できるようにしてるんだけど、Arch LinuxDropboxがいつからか常駐しなくなってて、それを直したタイミングで*.kdbファイルがコンフリクトしてしまった。

Dropboxのファイルはコンフリクトすると、競合コピー(confliected copy)とかってファイルを新たに作るので、自分でマージする必要がある。

*.kdbのコンフリクトは色んな理由でやっかいで、だいぶ辛かった。

KeePassには同期機能があるっぽくて、KeePass使えば解決じゃんみたいな話かも知れないんだけど、家のメインマシンがLinuxだったこともあって、KeePass 2.0が使えなかったか何かでKeePassXを採用してた経緯がある。

KeePassってMacOSXとWinでデータベースファイルの拡張子が違ったりしてたような記憶があるんだけど、今どうなってるんだろ?そもそも僕の勘違いで違わないのかな??

競合した内容を調査

当然、マージするには競合した内容を知る必要がある。

*.kdbはマスターパスワードをつかって暗号化されてるので、そのままで差分を知ることはできない。

どうやって差分を知るかというと、エクスポート機能を使ってテキストファイルかXMLファイルに吐き出すか、GUI上から超神技「目grep」を使うしかない。

僕みたいな一般人はエクスポート機能を使ってdiffを叩くなりするのがよさそうなんだけど、問題としてアホみたいに差分が出る。

実際見てみたけど、はっきり言って絶望しかない。

絶望した結果

golangを勉強してたので、XMLをパースして同じアイテムの差分を見て教えてくれるコマンドラインツールを書いた。

golangで書いておくと、WinでもMacOSXでもLinuxでも簡単に使えるやんけと思ったので、ちょうどよかった。

とりあえずどのアイテムがコンフリクトしてるのかが分かれば幸せになれそうだったので、その程度の作り込みしかしてない。

https://raw.githubusercontent.com/terut/kdb-diff/master/screenshot/screenshot1.png

こんな感じでマスターにあるやつとコンフリクトしたやつのアイテム名が出る。

github.com

まとめ

だいぶニッチだけど、golang書く練習になってよかった。

コンフリクト解消して幸せになろうな。

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

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

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

http://media.giphy.com/media/EYvXziUyue0Za/giphy.gif

やること

今回、ガイドラインやドキュメント、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、いますぐダウンロード に強い影響を受けた結果です。

続・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が来てたもんで、直ってんじゃないのとノリで上げてしまった。

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

http://media.giphy.com/media/rEii7ZHwUARaw/giphy.gif

対処法

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

で、今回はちょっと詳細に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

日本語WikiGrubの設定の部分が古くて、コードや上記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のこととか知らなすぎて辛い。

Arch Linux曰く、Something has gone wrong

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

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

体感では壊れることは滅多にないし、ググッて解決方法が見つからない、または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