作れないかもしれないけど作った話 at MF Geeks Night
TL;DR
最近Swiftに入門してて、作れないかもしれないけど勢いでライブラリを作った。 練習も兼ねて自分に必要なライブラリを作ると他のライブラリの作りを調べたりとかSwiftっぽい書き方とか目にできるので、学びがあってよい。 国家権力が白紙に戻すこともないので、作れないかもしれなくても勢いで作るぞ！！
LT at MF Geeks Night
先月に引き続き、@ppworks さんに声をかけてもらってMF Geeks Nightに行ってきた。 MF Geeks Nightについては MF Geeks Nightに行ってきた - 解せぬ日記 を見てもらうとよい。
LT募集です！と言われながらも、珍しく仕事が忙しいのとチキンなのがあって資料ができるか分からなかったのでLTに関しては返事をしてなかったんだけど、開始1時間前ぐらいにウオオオオオオオオオオオオオとなって資料を作り始めたら、雑すぎる資料ができたんで、枠空いてたらやることに決めた。
ピーさんが枠くれた時にはすでに話してたよね
— レベルがあまりに低い (@terut) 2015, 7月 29枠空いてたらやることに決めたはずなんだけど、気がついたらLTしてた。
まとめ
- 新しい言語をやるときにライブラリを作ると色々学びがあってよい。
- 作れないかもしれないけど作るぞ！！ぐらいの勢いが大事。
競技場に触れたかっただけかな？
MF Geeks Nightに行ってきた
TL;DR
プロダクトを作る上での文化が醸成されつつある雰囲気を感じつつも、自分で色々やっていけそうな余地もあり、楽しそうな職場だったんでオススメだと思う。興味ある人はぜひマネーフォワードに遊びに行ってみるとよさそう。
事の始まり
@ppworksさんがエスパーになった結果、MF Geeks Nightというのがあるからどう？みたいな話をもらった。以前から開催されていたようで、ブログにも様子が上がってる。
毎回ゲストを呼んで開催しているとのことで、他の会社の勉強会に参加するのは結構新鮮だった。
やったこと
毎回、面白くなるように色々考えられているようで、今回は社内の各チームの開発環境や開発フロー、取り組んでいることについて発表するスタイルだった。すごく色んな取り組みを自発的にやっているようで、各チームがよりよい開発を目指してたのが印象的だった。
一応外部の人間に言ってた内容なので、公開してもよい情報だろうけど、ハッシュタグなどはなかったんで、内容については触れない。
まとめ
とにかくマネーフォワード各位に勢いがあって、最終的に入社だぁ〜みたいな奇声を発するようになっていた。奇行種かな？
何が起こったのか分からなかったけど、とにかく勢いがある（大事なことなので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
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を使ってる。
そのデータベースファイルがコンフリクトするという地獄みたいなことが起きた。
経緯
Dropboxで*.kdbファイルを同期して、Win/Mac/Linuxで参照できるようにしてるんだけど、Arch LinuxのDropboxがいつからか常駐しなくなってて、それを直したタイミングで*.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でも簡単に使えるやんけと思ったので、ちょうどよかった。
とりあえずどのアイテムがコンフリクトしてるのかが分かれば幸せになれそうだったので、その程度の作り込みしかしてない。
こんな感じでマスターにあるやつとコンフリクトしたやつのアイテム名が出る。
まとめ
だいぶニッチだけど、golang書く練習になってよかった。
コンフリクト解消して幸せになろうな。
あなたとFacebook、今すぐサブミッション
Facebook Graph API 2.0に完全に切り替わって1ヶ月が経とうとしている。
Facebookのフィードに投稿するには、publish_actionsというパーミッションが必要なのだが、切り替わりに際し、パーミッションを聞くためにFacebookへのレビューが必須になった。
つまりレビューが通らなければ、そもそもユーザにパーミッションを求められないという話だ。
で、そのレビューを通して、知見を得たので残しておく。
やること
今回、ガイドラインやドキュメント、FAQを読みながらやったことは以下のような感じ。 はっきり言って大量にありすぎて、日本語訳作ってもすぐ腐ると思うので、原文を参照するのが好ましい思った。
- Facebookの定めるガイドラインを読む（必要になるタイミングでパーミッションダイアログを出すとかPrefillをするなとかタグ付けするユーザを簡単に選択・削除できるようにしろとかある）
- ガイドラインを守って実装する
- レビューの手順は明確にスクリーションショットを使いながら、どんなアクションを使うのかということまで説明する（書き方のヘルプリンクがあるので参考にする）
- レビューの際、レビュアーは自前でいくつかテストアカウントを持っているので、テストユーザ（オプションの項目）でテストして欲しければ、明記する
レビューの環境
いくつか方法があって、一番良さそうなのはTest Appを使うこと。 昔はTest Appという機能がなく、テスト用に単独のFacebookアプリを作ってテスト環境を作っていたが、それが本番に紐づく形で用意できるようになったので、それを使ってテスト環境を作り、 それをレビューしてもらえばいいかもしれない。 僕のケースではテストユーザの場合のみ、機能を解放するような仕組みを作って、それでレビューしてもらったので、上記の方法でやる機会があって成功したら教えて欲しい。
起こったこと
2回ぐらいリジェクトされた。 そして毎回同じメッセージで、どこを直していいのか分からない。
ヘルプを見ると、例えばログインできないなどの理由でレビューができなかったといった場合に返される結果らしい。 だがしかし、ログインできているし、管理者権限であればレビューがいらないので、機能を使えている。
で、どこか違反してたらもう少し詳しい結果が返ってくるはずなので、レビューすらされていないと考え、ひたすらレビューのための手順を詳しく用意し、スクリーンショットを追加した。 さらに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が来てたもんで、直ってんじゃないのとノリで上げてしまった。
ということで、本格的に格闘することにした。
対処法
ログの見方などは前回、説明した通りにやればよい。
で、今回はちょっと詳細に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もマウントしておく。
ここを見ながらやるとよい。
日本語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
あとはこれで再起動すれば無事にエラーは解消して、いつもの画面に会える。
まとめ
nvidiaのパッケージが対応しない限り、nvidiaのパッケージはアップデートできず、アップデートが億劫になるので、対応したほうがよいように思う。
あとCPUのこととか、Linuxのこととか知らなすぎて辛い。
