portal shit!

今年の夏は久々に Sunset Live に行った。福岡に引っ越してくる前の 2010 年の 9 月に行った以来なので 7 年ぶりだった。夫婦で酒を飲みたかったので JR とシャトルバスを乗り継いで行ったが、 10 時半頃に着いた筑前前原駅のバス乗り場は異常な混み具合で、結局会場に着いたのは 12 時過ぎだった。 Sunset Live はやはり早めに家を出て向かわないと厳しい。

Spotify 内で流れる BOSE の CM で知った The fin. という神戸出身のバンド（シューゲイザーっぽい音楽）が目当てで行ったけどいろいろ新たな音楽に触れることができて良かった。

まずそれまで食わず嫌いであまり聞いてなかった Suchmos のライブ演奏を聴くことができたのがよかった。和製 Jamiroquai という話は耳にしていたけど、確かに良いバンドだと思った。

次に PETROLZ の音楽を聞くことができたのがよかった。惜しむらくは PETROLZ の演奏中、絶賛夫婦げんか中でステージの正面で聞くことができず、メインステージの裏手の土手に体育座りをして聞いていた。反芻する度にだんだん良さがこみ上げてきて、 Sunset Live 後一ヶ月間くらいはずっと PETROLZ の Fuel を聞いてた。 PETROLZ にはすっかりハマってしまって来週福岡であるライブに行きたいと思ったが、すでにチケットは売り切れでチケットキャンプでは ¥27800/枚 😱 。貴重なライブ演奏をステージ裏で体育座りして聞いていたことが悔やまれる。

もちろん目当てで行った The fin. の演奏も良かった。あまりお客さんに彼らのことを知っている人が多くはなさそうなのが残念だったが、ライブで幻想的な Night Time を聴くことができて満足だった。

GW 前半の 4/29, 4/30 で山口県に行った。子どもが SL やまぐち号に乗りたがっていたのと、自分が下関の唐戸市場と角島に行ってみたかったから。旅行計画はこんな感じ。

家庭内 Kibela にエントリーを書いて嫁さんと共有しながら計画を練った。ただ嫁さんはめんどくさがって前日まで見てなかった。自分は電話が嫌いなので SL やまぐち号のチケット予約の電話を嫁さんにしてもらった。

予定では朝 7 時に家を出ることになっていたけどうだうだしてしまって結局は 9 時半頃家を出た。昼前に関門海峡に差し掛かり、関門橋を見渡すことができる PA で写真撮影して本線に戻り下関 IC で降りたところで嫁さんがシートベルトをしておらず後席シートベルト不装着で長州の官憲につかまえられた。関門橋のところの PA まではシートベルト着けていたとのことなのであれはトラップだと思う。ゴールド免許復帰の夢は潰えた。

下関市役所の駐車場に 11 時半頃到着し、歩いて唐戸市場へと向かった。下関の印象は門司と似ていた。昭和の雰囲気を色濃く残す寂れた商店街の感じは、あぁ、門司と下関は双子の都市なんだなぁという思いを抱かせた。

唐戸市場は昼時ですさまじい混み具合だった。ようやく食べ物を調達しても座って食べられる場所を探すのが大変。人混みの中で押し合いへし合い状態で買った海鮮丼は大したことなくて、唐戸市場はアクティビティとして来てみるのはよいけどわざわざ食事を目当てに来るほどではないなと思った。

テラスから関門海峡を通るタンカーや船を眺められるのはよかった。タンカー、普段は港に停泊してるやつか沖合を航行してるやつしか見ないと思うけど、間近で見るタンカーは結構速いスピードで動いてるという知見が得られた。

唐戸市場を出たあとは商店街にある自家焙煎のコーヒー屋でサイフォンでいれたコーヒーを飲んだ。

その後角島を目指して日本海側を移動した。海沿いの景色は福岡の糸島と同じような風景だったけど、とてつもなく長いビーチがあって気持ちよかった。角島には 4 時頃着いた。運良く空いたところに停められたけどすごく人が多くて車を停める場所を見つけるのが大変だと思った。この日は曇り気味の天気でガスも多く、角島大橋の景色ははっきりは見えなかった。橋を渡って角島の方まで行ってみたけど観光名所となっている灯台のあたり（映画の舞台になったらしい）は駐車場代が福岡の天神よりも高くバカらしくて車を停めはせずぐるっと回って戻ってきた。角島大橋近くの店でコーヒーを飲んで休憩したあと、併設の萩焼の店で嫁さんがいくつか器を買った。

6 時頃から今度は宿泊先の山口湯田温泉に向かった。途中、秋吉台を見ていきたいと思っていたけど道に迷った＆日が暮れてしまい、結局秋吉台を見ることはできなかった。 8 時頃ホテルに到着し、繁華街に出かけて食事をした。結構迷ってふらっと入った店は悪くはなかったけど会計がすこぶる高く卒倒した。宿に戻ると 11 時半を過ぎており、併設の温泉の利用を断られた。予約していた部屋がツインではなくダブルの部屋だったことを嫁さんにとがめられ床で寝た。

翌朝、朝食が無料で付いていたので食べに行ったところ、無料なのに地元のおばちゃんたちが作る煮物などがどれもおいしくびっくりした。チェーンのビジネスホテルで家庭の朝食みたいなやつが食べられて良かった。

食事を終えてチェックアウトし、コインパーキングを探して車を停め、メインの目的の SL やまぐち号に搭乗すべく湯田温泉駅へとタクシーで移動した。湯田温泉駅はつつじが満開だった。

SL やまぐち号は非常に混雑していた。また車両は古くてすすけていた。 SL は子ども時代に家の近所を走っていた ASO ボーイの試乗運転にしか乗ったことがなく、長距離を乗るのは初めてだった。 SL 特有の動き始めたときに車輪が滑ってずるっとなる感じが印象的だった。

やまぐち号の目的地は島根県の津和野で、車窓からの風景は山また山、時々田園地帯という感じだった。石州瓦の赤い屋根瓦の家々が印象に残った。日本海側で降雪量が多いことも関係あるのか、切り妻屋根の家が多いなと思った。

津和野は昔ながらの雰囲気を残す街だった。小京都と言われているようだが、中山道の宿場町の馬籠宿に似ていると思った。小さな街なことと帰りの SL までの時間が限られているのでレンタカーを借りるほどでもなかったので駅前でレンタサイクルをかりて街を回った。昼飯を食べなければならなかったが着いた時刻が 14 時前でどこの飲食店も軒並みラストオーダーを過ぎており、昼食を食べる店を探すのに難儀した。森鴎外の出身地とのことなので鴎外の生家に行ってみたかったが、三時間弱の滞在時間では時間が足りず、菓子屋で名物の源氏巻を食べ、閉店しようとしていたところを何とか滑り込んで割子そばとうずめ飯を食べ、酒蔵を二軒回って日本酒を買った（2本買ったうち1本は列車から降りるときに嫁さんが落として割った）ところでタイムオーバーとなった。

山口の湯田温泉駅に戻るとどっと疲れが出て、これから福岡まで運転して帰るのかと思うと暗澹たる気持ちになったので帰る前に足湯に浸かって帰った。街中に綺麗な足湯スポットがあって 200 円で入れて、足湯に浸かりながらコーヒーなどを飲むこともできる。

いろいろ盛りすぎて一泊二日で行くには時間が足りなかった。特に津和野にはもう一度行ってみたいと思った。

Qiita:Team エントリのレベルが高い

CEO や CTO 、プロダクトマネージャーの書く Qiita Entry のレベルが高く、 Qiita:Team のタイムラインがはてブのホッテントリのようだった。ブックマークできるもんならしたいという感じ。お金を儲ける仕組みってこうやって作り出されていくんだなぁと思いながら眺めてた。技術顧問の伊藤直也さんが残していった名エントリも結構あった。 Kaizen エンジニア行動指針とか。

SRE （インフラチーム）のレベルが高い

インフラが盤石だった。 SRE は二人しかいなかったがとても仕事が速く、困ったことがあって Slack のインフラ相談チャンネルで相談したらたいてい 3 分くらいで問題が解決してた。

yosudo さんは問題解決能力が高すぎていまは SRE ながら VP of GA （総務部門のドン）やってるし、 glidenote さんは SRE 業務をこなしつつも R&D して新しめの技術をどうやってビジネスにフィットさせていくかを追求したりしてる。

SaaS や IaaS をフル投入したモダンな開発体制

SaaS や IaaS を使うのはかっこいいからとかエンジニアが楽しいからではなく、その方が最終的にかかるお金が少なくて済むし、事業の圧倒的な成長に対応（スケール）できるから。詳しくは yosudo さんのスライドをご覧ください。

Mackerel meetup #7 スタートアップとSaaS

speakerdeck.com

コードのクオリティが高い

Kaizen Platform も 5 年目に入っているのでプロダクトのコードがレガシー化しているところがあるのは否めないけど、レガシーと言っても本当に悲惨なレガシーコードとは比較するべくもなかった。ユニットテストはちゃんと書いてあるし¹、インフラは AWS だし平均的な水準が高い。メインのシステムは Ruby と Rails で構築されていたけど、一部の機能を Go lang でマイクロサービス化したり、ログ集約サーバーは Node.js で構築されていたり、場所によっては C で書いて高速化してあるところもあり、特定の技術に依存するのではなく目的、状況に応じて柔軟に使う技術を選定していくところがこれまでにない感じだった。エンジニアが Ruby しかわからないから Ruby をずっと使いますというような消極的な技術選定ではなかった。

プロダクトマネージャーがいる

プロダクトマネージャー（ PM ）がいる会社で初めて働いた。データ取りとかは PM 自身ががんがん SQL 書いて取るし Domo や Redash などの BI ツールを PM 自身が使いこなしているので「○●のデータを本日 11 時までに大至急抽出してください！！！、！（現在 10 時）」みたいなことを割り込みで依頼されるということはなかった。プロダクトマネージャーは技術、ビジネス、市場、顧客のすべてに精通していてリーダーシップがあり、ミニ CEO のような人たちだと思った。

Kaizen Platform における BigQuery 活用事例 #bq_sushi tokyo #2 | PPTX

The use case of BigQuery in Kaizen Platform - Download as a PPTX, PDF or view online for free

www.slideshare.net

QA チームがいる

PM のほかに QA チームの人がいて、 QA 観点で動作検証したり仕様に指摘をしてくれてめっちゃありがたかった。しかも QA チームの皆さんが優秀。エンジニアが自分で作って自分で動作検証するのではどうしても先入観が入ってしまって検証が不十分になると思う。むかし働いていたブラック企業では午後 10 時まで開発したあと午前 4 時まで自分で作ったやつを動作検証してエクセルエビデンススクショ職人業もこなしてたけどあれは本当に不毛だった。エンジニアが作ることに集中できる環境はすばらしい。

社長が近い

社長室などはなく、 CEO も普通にフリーアドレス席に座って仕事しているので CEO がすごく身近な存在で話しやすかった。会社にいる人たちも CEO に対して従順というよりは、その道のプロの人たちが集まっていて、若い CEO を助けるために一肌脱いでる感じがあった。雇われているというより雇われてやってる感じ。 CEO のことを親しみを込めて「スドケン」と呼び捨てにするし、むやみやたらに上下関係を作って序列通りにひれ伏すのはださいという雰囲気があった。

セールスが強い

こんなに強力なセールスがいる会社で働いたのは初めてだった。砂漠でこたつを売ってくる男の異名を持つ人がいたり。元リクルートの人たちを中心とした精強なセールスチームがいて、大企業からどんどん契約をとってきてた。自分はこれまで中小零細企業とか上場企業でも個人向けサービスをやってる会社でしか働いたことなかったので、こんなに大人っぽいカッチョイイセールスの人たちがいる会社で働いたのは初めてだった。

社員の趣味がエクストリーム

雪山スキーとかサーキット走行とかフルマラソンとか雨が降らない限り毎週末キャンプしてるとか鎌倉に住んで毎朝サーフィンしてから仕事とか、社員の趣味がエクストリームだった。アウトドアでなくても仏像なぞり描きと御朱印集め、囲碁、観葉植物、美食、マイル乞食、不動産運用、マンション管理組合理事など、趣味が中途半端な人がいなかった。

性善説とアンチマイクロマネジメント

社員は悪いことをしないという前提で会社が動いているように思った。承認システムみたいのがあるにはあったけど、新しい SaaS を使いたいときには CTO に相談すればよかった。マイクロマネジメントを嫌う風潮もあり、休みをいつ取るかなどは自由だった。細かいマネジメントをする方が無駄にコストがかかるし、そもそもマイクロマネジメントが嫌いで大企業を辞めてきた人たちで構成される組織だった。

求められる水準が高い

マイクロマネジメントされない一方で、求められる水準は非常に高い。四半期ごとの目標設定と評価面談では、目標として設定したことをこなすだけではマイナス評価となる。目標を達成するのは当然で、求められていること以上の成果を出すことができたかが評価軸だった。

採用フローで期待されていることを説明される

自分が受けた頃は採用にとても時間をかけていて、これこれこういうことを期待しています、ということを丁寧に説明された。 2 回くらい現場の人と面接して最後に重役と面接して「お、キミいいネ、採用！」という感じではなかった。むしろ最初に CTO と話して次に CEO に口説かれ、あとから将来同僚となるエンジニアやプロダクトマネージャーと話すという感じだった。採用フローでポジションや求められる役割について説明があり、入ってから「俺はマネージャーだったのに平で雇いやがって」というような期待のミスマッチが起こりにくかった²。

情報が閉じられていない

会社の売り上げ、状況は公開されていた。毎週金曜朝から行われる All Hands で数字の共有があり、目標に届いていないなどのアナウンスがあった。また隔月で行われる全社合宿（合宿だけど日帰り）でも会社と事業の現状について説明が行われ、社員全員で今後の方向性についてディスカッションを行う文化があった。

仕事をしていく上で、会社の経営状況について知らされていることは重要だと思う。かつて働いていたブラック企業は顧客が自分たちにいくらお金を払ってくれているかを教えなかった（教えたら自分たちが搾取していることが従業員にばれるため）。お客さんがいくら払ってくれているかを従業員が知らないと払ってくれている金額に応じた仕事をすることは難しいと思う。

厳しいなと思うところもあるけど、意欲がある人には機会が与えられる職場だと思う。総じてパワーのある会社だった。

なんでこんなことを書くのかというと、実は Kaizen Platform を先月で退職していた。すべて自分の能力不足が原因で、決してペパボを辞めたときのような積極的な退職ではなかった。前回の退職は前進だったけれども今回の退職はまさに撤退という言葉がふさわしい。なので退職日に合わせて記事を書くことができなかった。

Kaizen では入社早々に障害を起こしてしまったり、アサインされたプロジェクトを頓挫させてしまったりで在籍期間中に大したバリューを出すことができなかった。

ただ Kaizen Platform で働いた 1 年 11 ヶ月は自分にとって非常に貴重な時間だったと思う。リモートワークのおかげでこれまでにない生活をすることができた。家族が忙しいときに家事をしたり子どもの幼稚園の送り迎えをしたり。普通のお父さんではできないようなことができた。

なにより通勤がないのが素晴らしかった。通勤は実際に移動してる時間は 30 分でも家を出る前の身支度が必要だったり、なんだかんだで朝晩に 1 時間ずつ時間を取られてしまう。家族がいる人の場合はこれが自分だけでなく家族の負担にもなる。通勤に取られる 2 時間があれば洗濯や炊事ができる。この 2 時間が生活にゆとりをもたらしてくれていたと思う。

ダイエットにも成功した。糖質制限をして減量したけど、普通に朝から出社して働いていたら食事の準備に時間をかけられず、摂取しやすい炭水化物中心の食事を続けていまもデブのままだったのではないかと思う。

半日休む必要はないんだけど、昼間数時間だけ自分のことに時間を割きたい、用事が終わったらまた仕事しよう、というようなことができたのがとても良かった。病院通いがとても捗った。

こういうの、ワークライフバランスと言ってしまえばありきたりな感じがするけど、ちゃんとワークライフバランスを保つのは尊いことだと思う。

反面、リモートワークにはつらい面もあった。何をやればいいかが明確ではない状態でのリモートワークはとても難しい（参照: リモートワーク）。チームメンバーの意識が統一されていない状況にもフィットしない。何をやるべきかを自分で明確にできる人、遠隔でもリーダーシップを発揮できる人でないとリモートワークはこなせないと思った。自分にはその両方が欠如していた。誰からも管理されない状況で自分でやるべきことを明確にし仕事をしていくのは自分で自分を律することのできる人でないと難しい。サボろうとしているわけではないのに時間だけが経過していくのは非常にもどかしかった。小さい頃から親や学校の先生に「次はこれをやりなさい」、「あれをやってはダメ、これをやってはダメ」と指示監督されてきた人間が突如として管理されない状態で働くのはきつい。管理されて働いているときは管理者に対して不満を持ちつつも、管理されないと全く何もできない自分の不甲斐なさが露わになるばかりだった。

全体として、自分に足りない部分がわかった 1 年 11 ヶ月だった。上に挙げた、リモートワークをうまくやっていくための資質（何をやるべきかを自分で明確にできる、リーダーシップがある）は、オフィスでより良い仕事をしていく上でも必要なものだと思う。また自分のやりたいことに貪欲であるべきことを学んだ。エンジニアだけでなく、セールスやカスタマーサクセスなど違う職種の人と話をしていて感じたことだった。やりたいことがあるのに黙ってもじもじしててもやりたいことは回ってこない。やりたければ相応の準備をした上でやりたいと手をあげないとやらせてもらえない。空気を読まず、遠慮をしないことが良い仕事をしていくために必要だと感じた。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。

リモートワーク舐めんなっつのhttps://t.co/CQCxFsVSsU pic.twitter.com/LorUJb0owC

— 森井ゴ (@morygonzalez) June 14, 2016

これがリモートワークです。 pic.twitter.com/PAR1hMbXve

— 森井ゴ (@morygonzalez) June 29, 2016

みんなリモートワーク最高だって言うけど世の中そんなに甘くないんですよ。これが現実です。 pic.twitter.com/rtA2t3oIY1

— 森井ゴ (@morygonzalez) July 7, 2016

これがリモートワーカーの孤独な現実です。 pic.twitter.com/rxIw5mUaUY

— 森井ゴ (@morygonzalez) November 7, 2016

だから言ったでしょう。これがリモートワーカーの前に立ちはだかる孤独な現実なんですよ。 pic.twitter.com/Hr7UKrQFmj

— 森井ゴ (@morygonzalez) November 29, 2016

これがリモートワーカーの悲痛な魂の叫びです。 https://t.co/FQh1p4iWhV pic.twitter.com/3jJuar6JWL

— 森井ゴ (@morygonzalez) January 20, 2017

結局リモートワークってこういうことだと思うんですよ。 https://t.co/IjIuED2ki1 pic.twitter.com/L3ePcgzb97

— 森井ゴ (@morygonzalez) January 24, 2017

なぜ IBM はリモートワークを廃止するに至ったのか…。その原因がこれです。 https://t.co/t0toQNysQs pic.twitter.com/azEzfgYeWp

— 森井ゴ (@morygonzalez) February 13, 2017

リモートワーク魂炸裂させてる。 pic.twitter.com/jtNdWrMyZy

— 森井ゴ (@morygonzalez) May 11, 2017

少し前に rebuild.fm で miyagawa さんが紹介¹されていた Chrome の Canary チャンネル²と stable リリースで Profile を分けて使うやつやってみたらとても便利。 Choosy.prefPane³ などのブラウザー切り替えツールとセットでやる必要があるので $10 お布施した。 Chrome は stable や beta など様々なリリースがある⁴が、 Canary チャンネルのみ独立した User Profile を指定できるようだった。

Choosy.prefPane は参照元のアプリケーションごとにブラウザーを指定したり（ Slack からは Chrome Canary とか、 Alfred からは Normal Chrome など）、 URL に応じて指定したり（ twitter.com は Normal Chrome など）もできる。これでミスって仕事用の Google Account で SaaS にサインアップしてしまったりということがなくなる。 とても便利。

Chrome への依存度が高くない人は仕事用に Chrome 、プライベート用に Safari のような使い分けでもよさそう。

平均の情報 - hitode909の日記

信頼性のない情報しか手に入らないときに人力で平均にするものの，あまり意味がない，ということがある インターネットを見ながら料理するとき，よくクックパッドを見ているけど，僕はクックパッドにお金を払ってないので，人気のレシピが分からず，その結果，いくつかのレシピを見て，うまく平均くらいになるよう作っている．どれか1つ決めて信じることができないので，リスクを回避しようと，平均のレシピになるように勘で調整している． その結果，まあまあおいしいけど，めちゃくちゃおいしいというわけでもないようなものができたりする． 以前のインターネットヤミ市でインターネットの平均のレシピのカレーが売られていた．ヤミ市のカ…

blog.sushi.money

自分は Tasty という BuzzFeed のレシピ動画を参考にするようにしている。自分も前はクックパッドを見ていたが、クックパッドにお金を払っていないため人気順でレシピをソートすることができず、検索してヒットする複数のレシピを見て比較したりするのに疲れてしまった。

Tasty は動画で料理が作られていく課程を見ながら料理をできるので楽しいし失敗しにくいと思う。映像や音楽もプロが作っているだけあって娯楽性が高い。 Tasty の問題点はレパートリーが洋食に偏ること。オリーブオイルどばどばで MOCO'Sキッチン のような感じになってしまいがち。あと簡単には手に入らない調味料を使っていることが多いので、カルディコーヒーなどの輸入食材店に足繁く通うことになってしまう。

手早く簡単に、家にあるもので何かを作りたい、という要求は満たせないかもしれないけど（クックパッドは冷蔵庫にある材料でレシピを検索したりできるのが便利）、料理を作ること自体が娯楽である人には Tasty はとても参考になると思う。

Lifehack (笑) 臭がしてこれまでキー入力拡張みたいなアプリケーションを使うのは敬遠してたんだけど（そもそもああいうのは IME がないアスキー文化圏の人向けだと思ってた）、 Pull Request 出すときのテンプレートとかを一発で出せたら便利だなと思ってその手のやつを使うことにしてみた。

有名どころだと TextExpander がある。試してみようとしたら何と月額課金に移行してて買い切りではなくなっていた。しかも結構高い（年額 $40）。いろいろ物色してたら昔何かの bundle で購入していた Typinator というやつがあって、こいつならアップグレード料金で使えるし買い切り型だったので使ってみることにした。新規で買っても EUR 24.99 で TextExpander の年間使用料より 1000 円くらい安い（24.99 EUR = 3061.5624 JPY）。

良く入力するやつを省入力できて便利

仕事で Zoom というビデオ会話ツールをよく使う。 Zoom には電話番号みたいに個人に紐付く固定の URL が存在してて、誰かと話したいときにそれを Slack 上に貼りつけて会話を始めたりする。この URL をいちいち Zoom を開いてコピペするのめんどいので ,zoom と打つと出せるようにしている。一瞬で MTG 始められて便利。

,dt と打って2017-03-11 のように今日の日付を表示させることも可能（入力キーや日付・時刻のフォーマットはカスタマイズできる）。こういう機能は ATOK にも付いているけどスペースキーを押したりリターンキーを押して確定したりしなくてよいのが快適。 ふむふむ～、ナルホディウスですぞ のような変換に何度も文節を調節したりしないといけないやつも ,naruho と打てば出せるようになってチャットが円滑に行えるようになった。

長めのやつも展開できて便利

冒頭に書いたように、 Pull Request 出すときに使ってる定型文みたいのがあって、過去の Pull Request からコピーしてきたりしていたのが一発で入力できるようになって異常に便利。 pullreq と入力するとシュバッと展開されるようにしている。こんな感じ。

ATOK に辞書登録するのとは違って改行を含んでいてもいいし、日本語入力モードに切り替えなくても良いのが便利。

inputrc で vi mode にしている Terminal (iTerm.app) で使うときの問題点

Typinator には GItHub みたいになってしまうのを抑制する機能がついてて、大文字が二文字連続したあとに小文字が入力されると自動的に二文字目を小文字に変換するという機能（ GItHub を GitHub に直してくれる）がついている。 Typinator は vi mode でシェルを操作しているとかは判別できないので勝手に補正してくれて上記のようなキーストロークが bbi と修正されてしまう。

Vimmer なのでシェルの操作モードを vi mode にしているのですけど、単語移動するときについつい

Shift + b Shift + b i

とか入力してしまうと Typinator が反応して bbi に補正されてしまってうざい。

設定に DOuble CAps Exception というのがあって例外設定できるみたいだったので BBi を追加してみたけどどうもうまく効いてないみたい…（ bbi に補正されてしまう）

さらに詳しく設定を調べてみると、アプリケーションごとにルールの有効・無効を切り替えられるっぽいので、 iTerm を使っているときは連続する大文字の小文字補正を行わないことにしてみた。これで様子を見てみよう。

Typinator types text for you

Insert words, sentences, or even entire paragraphs by just typing a few characters... Typinator expands it for you. Test Typinator now for free.

www.ergonis.com

Vim で Markdown を編集するとき、 vim-quickrun を使って Marked でプレビューするようにしてる。これが便利で体に染みついてるので、 Deckset で表示する用の Markdown スライドを Vim で編集しているときに一発で Deckset を開いてプレビューできたら便利だなと思ったので以下のようにしてみた。

1. ファイルのパスに slides が含まれていたら filetype を markdown.slide にする
2. そんで ft=markdown.slide のときは vim-quickrun で Deckset にファイルをプレビューできるようにする

こんな感じ。

au Bufread,BufNewFile /*/slides/*.markdown set filetype=markdown.slide
let g:quickrun_config['markdown.slide'] = {
      \ 'outputter' : 'null',
      \ 'command'   : 'open',
      \ 'cmdopt'    : '-a',
      \ 'args'      : 'Deckset',
      \ 'exec'      : '%c %o %a %s',
      \ }

便利。

GitHub - thinca/vim-quickrun: Run commands quickly.

Run commands quickly. Contribute to thinca/vim-quickrun development by creating an account on GitHub.

github.com

Marked 2 - Smarter tools for smarter writers

Marked is a Markdown preview with an elegant and powerful set of tools for all writers.

marked2app.com

Deckset for macOS and iOS: Presentations from Markdown in No Time

Write down your thoughts in your favourite text editor, and Deckset will turn them into beautiful presentations.

www.deckset.com