公式ドキュメントに書いてあるように、
-Xmx512m を -Xmx1024m とかに変更して RubyMine を再起動する
Atom でいま開いてるファイル（バッファ）のシンタックスハイライト用の言語を変更するコマンド名は "Grammer Selector: Show" か
— Kensuke Nagae (@kyanny) November 17, 2016
@kyanny 一方 RubyMine では Change File Language というコマンド名
— Kensuke Nagae (@kyanny) November 17, 2016
キーボード操作のみでやれると嬉しいと思う反面、コマンド名の覚えづらさを考えるとポインティングデバイスで変更するのでもいいかもしれない。頻繁にやる操作ではないし。
数年前に映画館で予告編を観て面白そうだと思ったけど結局観なかったんだよなぁ、と思って観始めたらなんか観たことある感じで、iTunes Storeの予告編を前に観たことがあったのかな？と思って（お金払っちゃったし）そのまま観続けたらだんだん話を思い出してきて「これ前に観たな…」そして観終わったあと「セブン」のデヴィット・フィンチャー監督と知って、ほどほどのグロさと後味の悪さはだからか！となった。肝心の内容は一度観たのに覚えてないくらいなので、たいして面白くなかった。
![ゴーン・ガール 2枚組ブルーレイ&DVD (初回生産限定) [Blu-ray]](http://ecx.images-amazon.com/images/I/51bKZjbN7hL._SL160_.jpg "ゴーン・ガール 2枚組ブルーレイ&DVD (初回生産限定) [Blu-ray]")
ゴーン・ガール 2枚組ブルーレイ&DVD (初回生産限定) [Blu-ray]
チャットや課題管理システムを使って非同期コミュニケーションをしていると、誰かに向けて発せられたけど誰も応答していない、ルーズボールのようなメッセージができてしまう。こういうのを見かけたら、できるだけ拾うようにしている。
Quipper の Slack には #development という公開チャンネルがある。開発者が開発にまつわる話をする場で、開発者向けの #general チャンネルといった位置づけだ（なお、開発者向けの #random に相当する #slackoverflow というチャンネルもある）
#development は公開チャンネルなので、開発者だけでなく、営業・マーケティング・カスタマーサポートなどの部門で働く人たちも参加している。時折、彼らがシステムのことで何か困っていて、開発者の手助けが必要なことがある。そういうとき、誰でも構わないからちょっと見て欲しい、という意図で特に誰も指名せずに呼びかけられると、みんな「誰かが反応するだろう」と思ってスルーしてしまい、誰も反応しない、そのうち別の話題でログが流れてしまい、ますます反応されづらくなる、ということがおこる。それはよくないのでスルーせずちゃんと反応しよう、と思ってほどほどに気をつけている。
こういうコミュニケーション上の行き違いは職種に限らず起こるものなので、個人の姿勢という点では「エンジニア立ち居振る舞い」とは関係がないかもしれない。けれど、あえてお題に投稿しようと思ったのは、単に自分が「いいひと」だと思われたいからではなくて、チームの一員であるエンジニアの立ち居振る舞いとして、特筆すべき点があると考えているからだ。
エンジニアが大勢いるのに誰も反応しない、という状況は良くない。手助けを求めている人からすると、「エンジニアは自分の呼びかけは無視するくせに、エンジニア同士の話にはすぐに返事をしていてひどい。不誠実だし、信頼できない」と感じてしまうかもしれない。たとえ、その呼びかけの内容に明るい人がその場におらず、他の人たちはちょうどサービスに障害が発生していて対応のためのやり取りをしていた、みたいな状況だったとしてもだ。 Quipper は世界中にオフィスがありコミュニケーションを難しくする要因がいくつもあるので、信頼関係を築くのがより一層大切になってくる。些細なことで信頼を失いたくはない。
ルーズボールを拾ったからといって、最後までボールを持ち続けるわけではない。むしろ、ふさわしい誰かにパスすることのほうが多い。実現が難しいリクエストに対して「ごめん、それは無理です」とつれない返事をせざるを得ないことも少なくない。それでも、顔の見えない「エンジニア」を頼りにしている人に対して、ぼくたちエンジニアはあなたのことをちゃんと見てるよ、と一言伝えることには、意味があると思う。
窓口担当者を決めたほうが良いのではないか、という意見をいただいたので補足したい。
そういう仕組みはすでに用意している。詳しくはDeveloperの問い合わせ対応との関わり方 - Quipper プロダクトチームのブログに譲るが、これと似た仕組みが日本以外でも運用されている。
にもかかわらず窓口を通した正規のフローからもれる依頼はでてくるもので、大別すると以下の三種類がある。
1. 依頼者が窓口の存在を知らない は窓口があるよと案内して終わりで、 3. 緊急事態 は正規のフローを踏んでいる場合ではないのでその場にいる人たちで対応する。残った 2. 依頼内容の実現可能性を知るために粗い見積もりが欲しい が見過ごされがちなので球拾いしていきたい、という話です。
2. 依頼内容の実現可能性を知るために粗い見積もりが欲しい も各人が能動的に拾うに任せるのではなく、「わからなかったらこの人に聞け」という、一次請け的な窓口担当者を置く方法もあるが、それは悪いアイデアだと思う。名指しで依頼される仕事が増えると透明性が失われる。すると属人性が高くなってチームメンバーが交代しづらくなり、窓口担当が固定化されて疲弊するもとになるし、窓口担当者を変えたくても引き継ぎが難しくなったり、窓口担当を離れているのにプライベートチャットで仕事を頼まれたり、悪循環がうまれる。
ルーズボールを拾い始めると名指しで頼まれることが増えてくる。頼りにされるのは嬉しいことだけど、「チームとして信頼を勝ち取る」という目的にそぐわないし、自分が仕事を引き受けすぎてパンクしては元も子もないので、そういうときは「私個人としてではなくチームとして仕事をしているので、指名せずチーム全体に呼びかけてくれ」とお願いしている。
I made Solarized Light / Dark themes for Quiver.
I've used Solarized themes sometimes in my favorite editors (Vim, Emacs and RubyMine). I like it. Now I'm using Quiver, so why not use Solarized?
Unfortunately, Solarized themes didn't exist for Quiver. Fortunately, Quiver allows me to make custom theme, and Solarized makes its color scheme public, so why not create theme?
It was a really fun weekend project. I looked into how to use Solarized color scheme. When I read Solarized homepage, I was impressed by its principles very much. I also looked into how to make custom theme for Quiver. There was a great document How to Design a Custom Theme that helped me to understand the way. I also learned that how can I customize markdown cell's background (and so on) from built-in Spacegray theme (I could export it so I could read its settings).
