転職して1ヶ月が経っていたようです

タイトルのとおりです。
いつものも置いておくのでよろしくお願い致します。誰からかわかるとうれしいです

http://amzn.asia/ehpcSIc

(毎度のことなんだけどkindle版をほしいものリストから贈れるようにしてほしいし、並び替えはかんたんにできるようにして欲しいし、並び順は覚えておいて欲しいんだけどなあ……)

さて、2017年6月末日づけで某社を退職し、7月1日づけで、某お金を前にするような会社に勤めています。
職種としてはいわゆるWEB系プログラマー(サーバー寄り)という感じです。変わんないですね。
インフラまわりに手を出さなくなったのが前職との違いだと思います。

これは転職とはあんまり関係ないのですが、ついでにせっかくの機会なので一人暮らしを始めてみました。
さらには脱vimしてRubymineを使ってみたりスプラトゥーン2で3D酔いしてみたりしています。

引っ越しのドタバタで6月末の振り返りをすっとばし、なんやかんやで7月の振り返りもすっとばし現在に至ります。
環境が変われば現在の自分に感じる課題というのも変わっていて最近は日々頭を抱えているのですが、うまく言葉にできなくてなんだかにゃーとずっと言っています。
ぜんぶうまくいけ

さて、繰り返しにはなりますが、そんな悩めるカエルへの温かいご支援をお待ちしておりますのでなにとぞ

http://amzn.asia/ehpcSIc

Linux + Thinkpad X1 Carbon 5th Genでトラックポイント、タッチパッドが安定しなかったけど直した話

解決したから書く

環境

Thinkpad X1 Carbon 5th Gen
Ubuntu 16.04(Arch使ってたときも現象は同じ。治るかは未確認)

現象

タッチパッドトラックポイントがうまく動かない。
具体的には0.5秒くらい動いたあとに動かなくなる。
また何回か動かしていると10秒に1回くらい動く。

やったこと

参考に書いてあるブログ記事の内容を2つ試したら動くようになった。
ためしてないけど2つ目だけで動くかもしれない。

  1. カーネルパッチ当てる
  2. 以下のコマンドを叩く
sudo modprobe -r psmouse
sudo modprobe psmouse proto=imps

なんか2つ目だけでなおりそうな気がするけど。

参考

fredrik.wendt.se

Dockerのイメージとかタグとかの云々

だいたいこれで終わりだが一応書いておく。

前提その1

Docker は image をもとにして動く。image は Dockerfile に定義を記載しビルドすることで得ることができる。自分の image を作成するときには他人が作った image をもとにすることができる( FROM で記載する)。それらを共有する仕組みとして Docker Hub という Docker image を多数ホスティングしているところがある。

前提その2

Docker imageは名前とタグで管理される。名前はURLみたいなもので、 (host/)?(namespace/)*image_name という形式で表される (気がする)1
host が省略されていればDocker Hubという意味。namespace はそのホスト毎に管理が違う。Docker Hubだとユーザー個人のものはユーザー名のネームスペースに置かれ、公式と認められたものはネームスペースがない。

例: nginx → Docker Hub にある nginx という公式イメージ
例: hkdnet/app → Docker Hub にある hkdnet さんの app というイメージ
例: hkdnet.net/nginx → hkdnet.net という Docker registry の nginx

タグは同名イメージの中で区別するためのもの。イメージ名のあとに : を続けて記載する。だいたい公開されているものはメインのソフトウェアのバージョンを示していることが多い。自分のアプリケーションを Docker image にするときはブランチ名とタイムスタンプかCIのビルド番号をつけている。

例: nginx:1.12
例: ruby:2.4.1
例: hkdnet/app:master-build001

タグは好きなようにつけてよいし、一度 Docker registry に push されたイメージのタグも簡単に書き換えることができる。タグはイメージにおいて一意でなくてはならないので同名タグを push した場合は古いイメージについているタグは新しいイメージに移動する。

例: 4月に app:latest を push
5月に app:latest を push
このとき app:latest は5月のほうに移動する。4月のイメージのlatestタグは剥がされる。

余談だが Docker image には複数のタグをつけることができる。Docker image の一意性を担保しているのは Image ID であり、名前とタグはImage ID への参照だと言える。

先程の例をもうちょっと複雑にするとこんな感じ。

例: 4月にビルドしたイメージのIDを APRILXXXXX とする。これに app:latest という名前をつけ push する。また app:201704 という名前をつけて push する。
5月にビルドしたイメージのIDを MAYXXXXXXX とする。 これにも app:latest という名前をつけ push する。また app:201705 という名前をつけて push する。
このとき app:latest は5月のほうに移動する。4月のイメージのlatestタグは剥がされ、参照するには Image ID を直接指定するか app:201704 として参照すればよい。2

Docker image は基本的には FROM 指定したり run したり compose に書いたりするといい感じに pull される。しかし、ローカルにキャッシュがある。また、キャッシュヒットがタグ名で行われる。この2つによってタグまで一致するものがローカルにあると自動で pull されなくなる。
具体的にどういうときに困るかというと4月時点の app:latest が手元にあると5月で更新されたとしても app:latest は古いものを指したままになってしまう。対応策としては明示的に pull すればよい。あるいはローカルの app:latest のタグを消すか。


さて、 Docker を語る際のよい点に環境が変わらないことが挙げられることが多い。確かに同じ Dockerfile からは同じようなイメージが作られると期待できるが期待は裏切られることがある。

その1つが FROM 元の変更である(ようやく本題)。
Ubuntuは上述の公式イメージがある。だがそんなものを見なくても俺はUbuntuの最新LTSが16.04なのを知っている。

FROM ubuntu:16.04

ということをやると冒頭のように死にます。

https://hub.docker.com/_/ubuntu/

xenialも日時バージョン付けているのでちゃんと日時バージョンまで指定しておきましょう3


  1. 分類は公式に決まっているのかは調べてないが、だいたい使っているときはそう捉えておいて問題ない程度の意味

  2. さすがにアレなので図がほしいがめんどい

  3. 本題に対して前提が長すぎる……

Credenatial Management APIの発表聞いたメモ

developers.google.com

僕はchrome使いなのですが、まあモダンなブラウザを使っている皆様ならばだいたいログインフォームに入力したあとに「このログイン情報を保存しますか?」系のダイアログが出るのをご存知かと思います。
インターネットの普及に伴い様々なサービスをwebで享受することが可能になりました。webを見るのはだいたいブラウザでしょうし、各ブラウザベンダーとしてはwebサービスが増えていること、webサービスを使う人が増えていること、webサービスが扱う情報がより重要なものになっていることなどからブラウザでのログイン、セキュリティまわりもよくしていかないといけないよね、という問題意識があるような気がします[要出典]。
またスマートフォンの普及にともなって1人の人間が使うデバイスが複数あることが一般的になりました。そうするとPCでのchromeandroidchromeでログイン情報を同期したいというのはユーザーの要望として当然のことですし、webサービスとしてはユーザー体験を損なわないように努力する価値があるところでしょう。

というわけで Credential Management APIwebサービス開発者として結構気になる内容なのでトークをざっと聞いてみました。
以下そのまとめとメモです。
メモは話していたことを雑にメモってあって、 memo: で始まるのが僕が思ったことです。

まとめ

  • Sign-UpにCredential Management APIを使うのはめちゃくちゃよさそう
  • 一方でweb標準なのか?という疑問が残る
  • ブラウザに寄せたい人にはいいけどそうでない人はどうするのがいいんだろうなーという懸念がある

メモ

主な関心事は3つ。Sign-In, Sign-Up, AuthN1
Sign-Inがサインイン・ログイン時の話で、ある登録済みユーザーがあるサービスを利用開始するときの話。
Sign-Upは初回登録時の話。
AuthNは認証の話。特に2FAにフォーカスしてた気がする。

memo: AuthNが一番よくわからんかった

Sign-In

chromeのパスワードマネージャがうまく動かない理由トップ3

  • マークアップが壊れている、アノテーションがおかしいなどHTMLレベルの問題
  • サインインフォームである、サインインに成功したとchromeが検知できない
    • chromeは遷移後の画面にまたフォームがあるとログイン失敗とみなす
    • fetch APIなど画面遷移を伴わない場合は history を操作することで navigation が発生したとみなしてくれる
  • HTTPとHTTPSが混ざってる
    • HTTPなページにHTTPSなフォームがあっても insecure である
    • HTTPページの改ざんの可能性があるのでjsを仕込んでpasswordを別サイトにも送信、とかができちゃう
    • 当然HTTPなページにHTTPSのiframe仕込んでもダメ

chromeがランダム生成した文字列をパスワードにしてくれる機能がつく2。ランダム生成したものをchromeに覚えさせるので推測されにくくなる。自分で覚えてないからフィッシング詐欺にも遭いにくくなる。

memo: これいつデフォルトでオンになるんだか言ってたっけかなあ

Sign-Up

Credential Management APIでやるといろいろいいいことがある

  1. アカウント選択画面が画面が出てワンタップしたらログインみたいになる
  2. 規格に対応している認証情報提供元ならどれでも使える
  3. 入力のめんどうがない
    • ECサイトとかの事例で登録率とかコンバージョン率がめっちゃ改善した例が載ってた
    • memo: こういうの、UIの改善も同時に行ってそうな気はするのでほんとに独立な結果なのかわからんというかそうでない気がするが、フォーム入力の完了率を気にすることがなくなるのでマジで重要っぽい

こんな感じで使う

let settings = {
  password: true,
  federated: {
    providers: [
      "https://accounts.google.com"
    ],
  },
};
navigators.credentials
  .get(settings)
  .then(credentials => {
    // ユーザーに「これ使っていい?」あるいは「どれ使う?」ってダイアログが出る
    // ユーザー操作で選ばれたらresolveされるっぽい
  });

memo: これweb standardになるのかなあ。そのへんがよくわからん

AuthN

memo: けっこーはやくちなのでツラかった

いま2FAといえばOTPだけどsecurity keyというのを使うようにしたい。
security keyはデバイスに挿して使うやつでワンタップすることで二段階認証OKということにできるっぽい。
memo: 仕様としてはFIDO Universal 2nd Factorというやつっぽい。


  1. AutheNtication(認証)の略。AuthZ(AuthoriZation, 認可)との区別のために使う略語だと思う。認証とは「ユーザーが確かにこのアカウトであるか」という本人確認のこと。認可は「このユーザーならこの情報は見てもいいよ」などの許可だと思ってればよさそう。

  2. Chrome 59だとまだデフォルトではオンでないっぽい。 chrome://flags でいじれる。参考 -> How to Automatically Generate Random Secure Passwords in Google Chrome?

podcast #しがないラジオ sp03 にゲストでいってきました

友人がpodcastを始めたというのは以前に書きましたがそれにゲスト出演してきました。

shiganai.org

好き放題喋ってたら3話構成(3a, 3b, 3c)になるくらい喋っていたようです。3aでは仕事の話、3bでは勉強会とかの話、3cではキモオタトークをしています。ちなみに僕はオタクではないです。

初めてのpodcast出演だったのでちょっと思ったことをまとめておきます。

喋り方について

どうも自分の喋り方として声のボリュームの調節を多く使っているようです。強く主張したいときには声を大きく、自信がなさげなときには声を小さくというような表現。たぶん誰もがやってるとは思うのですが僕のは他の人より顕著だと思いました。この手法、普通に話してる分にはいいけどpodcastだと結構厳しい印象です。小さく話しているときにボソボソ声になりすぎている箇所があったと思います。3aから3bの間に休憩いれたので3b以降は収録しているのを忘れているフシがあって、結構聞き取りにくいところが目立ったなあというお気持ち

喋るタイミングも難しい。相槌はうたないように気をつけていたのですが、何かのトピックについて話しているときに、話したがってそうな人がいるのにそのまま話しちゃったりしてました。3a冒頭でずっきーさんが「3つほど質問がー」っていってあとから質問してるのとかがいい例ですね。ガミさんと喋るのには慣れているし、席が隣だったのもあってガミさんとばっか喋ってたのも反省点。
これは挙手制とか採用したらいいんだろうか。2人のpodcastのほうが調整しやすそうだなと思います。まあゲストなので好き放題しゃべっててもいいのかもですが、ゲストとの対話でメインパーソナリティの普段見えない一面とかを引き出せるのがいいゲストなのではなのでは?という気持ちもあって、うまくやれてないなーという感じ。

僕は普段の会話からかなり早口なのですが、今回のpodcastでもそれが遺憾なく発揮されていた気がします。エクセルスクショと言ったときとかがかなりギリギリだった、というか聞き取れない人もいたのではないかと思った。すみません。
これは改善策は、どうしたらいいのかなーとずっと悩んでます。podcast出演時に限らず自分が興味があることに関しては早口で熱っぽく語ってしまう悪癖があるのですが、これが全然直らない。日常生活でも支障があるので対策が欲しいのですが……。

全体的には、まあ自分の声ってこんな感じなんだなーっていうのが認識できて良かったです。冒頭10分くらいは「誰コイツ?」って感じの気持ちが強かったのですが聞いてると慣れるもんですね。他人に向けて話す機会というのは人生そこそこあるのでこういう機会で練習しておくのはいいことかもしれません。

内容について

反省点として、まず最初に挙がるのは、僕の略歴とか興味ある人いるんかいなっていうところですかね。結構長めに話してしまったのだけど、もっとざくっと終わらせてもよかったのでは。前職紹介みたいな感じになってるし。

.NET FrameworkC# について話すときに、 JVMJava の関係はみんなわかっているものとして話していたけどそのへんの説明もいるんじゃないかなあと聞き直して思いました。このへんはリスナーのレベルをどう見積もるかという話でもありますが。しがないラジオのリスナーはプログラマーではないことも結構あると思うので難しい。とはいえ普段聞いてるともっと技術寄りの話してほしいって思うときもあるしなあ。

勉強会の話は、やっぱお世話になってるところのは宣伝しよーと思っていて、 ninirb と どう書く の宣伝をしました。ちなみにどう書くもninirbもsp3が公開されたあとに既に開催されたんですが、誰もしがないラジオから来ましたって言ってくれませんでした。かなしい*1

友人から一番好評だった3cですが、ちょっと各マンガの紹介がさっぱりしすぎていたかなと。それぞれ思い入れがあるので話せばもっと話せるのですが、ネタバレを避けつつヨサを伝えるとなると難しいですね。僕はシチュ萌え派なので「あのときあの場面でアイツがこういう行動とったのほんとよかった」みたいな話がしたいんですよね*2。でもだいたいネタバレそのものなので話せない……。これは、こんどまたどっかで呼んでもらう予定なのでそのときにネタバレ上等として話せればいいかなーと思います。
他に、つらつら紹介しまくったのでちゃんと紹介したいのを網羅できなかったのが残念ですね。絶対『青春のアフター』の話をするぞというのは決めていたので、最低限それはクリアできたのですけど。このへんも紹介すればよかったーってのがこのへん。

フィードバックでオススメされたLandreaallも全部読んで面白かったのでこれも次回話すかもです。

*1:しがないラジオの宣伝力が足りないのか僕のアピール力がたりないのかは考えないでおきます

*2:3cで話していたけいおんのりっちゃんのエピソードみたいなやつ

2017年5月振り返り

記録

total: 10839 minutes
Rank    Name    Minutes
1   Ruby    2654
2   JavaScript  1541
3   PHP 1456
4   Git 1171
5   YAML    853

雑感

記録から

んー、だんだん減ってますね。
5月病だから仕方ないよね、という話ではなくこれには理由があって、つまりはゼルダです。アレマジヤバイ

ゼルダはまあまず間違いなく50時間くらいはやってる気がするのですが(こわくてはかってない)それで3000分ってことですね。
あとArch Linuxのセットアップをちまちまやってたのですがこれはwikiを読んではコマンドを叩くという作業なのでコーディング時間には反映されてません。

Rubyがメインなのはいつもどおりですが、次にJavaScriptが来てるのがちょっと意外ですね。なんでだろう。
JavaScriptは友人に教えるためにちょこっと書いたり、管理画面のフロント側がイケてなかったので思いっきり書き直したのはそうなんだけど、管理画面の書き直しとかそんなに頑張ってないし予想より多いって感じですね。テストデータがJSONだからテストデータいじってたときの時間が計測されてるのかしら。

PHPはまあ、副業のほうですね。5月にリリースしたい機能があったのでがんばりました。はい。
頑張った割にはあんま書いてないですね。先月と同程度だし。なんでだろう。

記憶から

5月のメインは、まあなにをおいてもゼルダなのですが、それはまあ置いておくとすると、しがないラジオに出たことですかね。
もうだいぶ前の話になりましたけどこれは別記事で書きます。

それ以外に記憶に残ってるのは、やったことでいうとArch Linuxのセットアップが大きい。いや、終わった風に書いてるけど全然終わってないです。 Linuxをイチからセットアップするのが初めてで、わかんないことだらけで困りました。今も全然わからんです。

とはいえ一応最初からやることでいろいろわかってきたこともあって、普段何気なくつかっているGUIがどういうレイヤーが積み重なって実現されているのかとか、NICまわりのところとか、キーボードまわりとかの理解が深まってきた感じがあります。仕事の役には全く立たなさそうなんだけどこの調子で続けていきたい

仕事は、まあいろいろやってたんだけど、タグつけたらリリースしてgem公開してgithubのp-rマージしてタグつけてdocker build and pushしてくれるようなやつが完成したのがたぶんいちばんデカい。紆余曲折ありながらも頑張った感がある。

そういえば純粋関数型データ構造は買って3章くらいまで読んで積んでますね。StandardMLむずい。再開します。

友人にNode.js教えてます。教えるってほど手とり足取りじゃあないけど。
「こういうのしたい」 → 「だいたいこんな感じでいいのでは(サンプルp-rポイ」
「gitでこういうことしたいんだけど」 → 「わかばちゃん本のp.XX見て」
背中で教える的な感じになりがちなのでモチベコントロールがちゃんとできてなさそうなのが懸念なんだけど、まあ別に友人相手だし(= not 仕事)飽きたらやめちゃってもいいし、またやりたくなったときに聞きにきてくれればいいような気もする。

Re: Slackのスレッド機能をどう使うか

hkdnet.hatenablog.com

結論

  • スレッド使うのやめよう
  • スレッドで発言するならチャンネルに表示しよう

理由

比較したときにデメリットのが大きいと思う。

デメリット

  • 他の人がスレに発言があったかどうかわからない
  • 何してるのか見える、何に困ってるのかわかるという分報のメリットが消える

メリット

  • 見た目スッキリ

1タスク1スレッドくらいならまだいいのかもしれないが(この運用やってる人いないからわからんけどたぶん良くないとおもう。後述)、当初の目論見である「1日1スレッドで日報まとめるといいかも?」というのは完全に間違いだったと思う。

と、ここまでは分報的なスレッドの使い方の話。このことを考えてるときに思いついた意見も書いておく。今度はスレッド全体に一般化したときの話。

slackのよさの1つは、subscribable で self-controlable であることだと思う。チャンネル上での発言は基本的に全部通知がいく。受信者は自分にとって必要なチャンネルを選択し( subscribable )、自分にとって必要な通知レベルでそれを管理している( self-controlable )。特に前者の「受信者が情報を選択する」というのが大事でこれによって情報の透明性というか組織の情報共有のレベルがあがると思っている。
一方でスレは subscribable ではない。通知の有無は発言したことがあるかどうかで決まるし、そのレベルはチャンネルに依存する*1。乱立するから「あ、これウォッチしなきゃ」と思って :eyes: とか打つのもダルい。というかやったことない。スレ内発言をチャンネルに表示するかは発信者の裁量になっている。
つまり上で書いた subscribable + self-controlable であるというよさがなくなるのでスレが日常化するのはよくないと思う

例外的に使っていいのは、チャンネルに表示するとき。これは subscribable + self-controlable であるというよさをそこなわず、一方で必要な情報を1つの発言へのスレッドとして保存できる。slackは発言1つに対してURLがつくので元発言のURLでスレッド全体を指せる。これは素直に便利なので使うといいと思う*2

というわけで改めて。

  • スレッド使うのやめよう
  • スレッドで発言するならチャンネルに表示しよう

いずれアンサーエントリ書いてみたいという気持ちはあったがまさか自己言及で実現するとは思わなかった

*1:たぶん。違ったらすみません

*2:一方で必要な情報だけどスレ内発言にし忘れたものをどう拾うかという問題はある