valid,invalid

関心を持てる事柄について

会社ブログでは固有の文脈・ユースケースにフォーカスした話を読みたい

いつもお世話になっている TechRacho の以下の記事を読んでいて気になったこと、思ったこと。

TechRacho(自社技術ブログ)に関連したあれこれ、2年毎日更新してみて感じたこと

これだけ見てくれる人が増えたらちょっとは採用応募が増えるかなと期待しているのですが、アクセス増のわりには増えないですねー。TechRachoはわかるけど、BPSのことはよく知らないしなー、なのかしら。あるいは、コンテンツ配信だけだと、どんな技術者がいて、どんな開発をしているのかわからない、なのかしら。それとも両方?

おー、そういうものか…と驚きもあり、最近の自分の考えを補強するものでもあった。(確証バイアス)


TechRacho とは運営趣旨がだいぶ異なるものの、弊社もQuipper product team blogをやっている*1。PVは TechRacho にはまだまだ及ばない。

ブログのおかげで採用大成功していますと喧伝するほどではないし、そもそもブログ単体に採用への直接的貢献を求めていない*2けれども、以下のような事例が増えてきた。(定性的意見)

  1. 面接時に「ブログで知りました」「ブログ読んで応募しようと思いました」と言ってくれる
  2. 最近入社された方が「ブログも入社を決める一因となった」と言ってくれる

2の方の意見からいくつかピックアップして要約する:(N=2)

  • 普通は見ることができない社内のやりとりを見られることで、どんな雰囲気で仕事をしているのかがイメージできて親近感が持てた
  • 情報発信をしている企業は結構あるので、どちらかというと量より質が大事
  • 採用ページや Job Description はどうしても抽象的な話になるので実務ベースの話の方が参考になる

現時点では全くもって定量的ではないのだけど、採用を目的の一つに置くような会社ブログでは会社固有の事情や文脈やユースケースにフォーカスした方が良さそうだと考えている。というか自分ならそういうブログが読みたい。


以下は会社ブログに限らない話:

内容の"質"が高いことは大事だが、技術単体に関する話はたいてい公式のドキュメントを読めば良く、ものによってはすぐに陳腐化してしまう。

だからこそ、ある文脈でなぜそれを選んだか・どうやって抱えている問題を解決したか・またはなぜそのやり方で解決できなかったか・これからどうしていくか等々を語ることや、その実践のログを通じて発信者(会社・個人)の思考様式を外部から評価できることに価値があると考える。

ユースケースや文脈抜きでの技術選択や評価を盲信するな」という意見にも通じる。

*1:同blogの趣旨については なぜこのブログは「エンジニアブログ」ではなく「プロダクトチームのブログ」なのか - Quipper Product Team Blogを参照

*2:AIDCAメンタルモデルによる Attention(注目)→Interest(興味)→Desire(欲望)辺りは期待している

必要なときだけ Polyfill.io のCDN から polyfill を読み込むようにする

以下のような script tag を HTML の最初の script tag として埋め込む。

<script>
(
  function(doc){
    if([].find&&window.fetch)return;

    var firstScript = doc.getElementsByTagName('script')[0];
    var scriptToInsert = doc.createElement('script');
    scriptToInsert.src='https://cdn.polyfill.io/v2/polyfill.min.js?features=Array.prototype.find,fetch';
    firstScript.parentNode.insertBefore(scriptToInsert, firstScript);
  }(document)
)
</script>

無名関数の1行目で polyfill が必要かどうかを判定する。

必要であれば、cdn.polyfill.io から polyfill を得るための script tag を document に埋め込む。

doc.getElementsByTagName('script')[0] より前に insert しているのは polyfill が読み込まれる前に script が実行されるのを防ぐため。


Polyfill.io については https://polyfill.io/v2/docs/api を参照

gem install することなく Slim, Haml, Pug を HTML に変換する

Rails の view を React で書き直したときに使った脱 Slim のやり方

各種 gem を install して手元でコマンド叩いてもできるけど面倒くさい場合に使える

結論

converter - How can I convert html.slim files to html or html.erb? - Stack Overflow この回答どおり、CodePen に Slim などを貼り付け、コンパイルされた結果を参照すれば良い

詳細(Slim の例)

StackOverflow で記載されていることに特に付け加えることはないが…以下のやり方でコンパイルされた HTML が見られる

  1. CodePen で新しいプロジェクトを作る
  2. HTML 入力欄の歯車をクリックし、 HTML Preprocessor として Slim を選ぶ
  3. 変換したい Slim を入力する
  4. HTML 入力欄の逆三角をクリックし、View Uncompiled Slim を選択

image

f:id:ohbarye:20180731231632p:plain

余談

HTML2slim は HTML -> Slim の単一方向のみ

CodePen でなくても出来るとは思う

「○○の経験したこと無いくせに」と経験者が語ることについて

「○○の経験したこと無いくせに」

「○○したことないからわからないんだよ」

という言説を見聞きしたり、この論旨で「論破してやったわ」みたいなの Twitter で見るたびげんなりしてしまう。

こういう反論でも良いと思うけどちょっと論旨がずれそうだ。

トラブルを避けるためにちゃんと理解してもらいたいのは、相似する、もしくは全く同じ経験をした人間が自分と同じことを知ったり学んだり思ったりするわけではないということ。自分の個別的な経験・思考を、一般的な事例や法則へと置き換えてしまうのは過度な一般化だ。

学校で一斉授業をうけていたこととその結果を思い出してくれるとだいぶわかりやすいと思うのだが…自分の観測範囲では、人生にとっての一大イベントと当人が考えるような事象については驚くほど多くの人が他人に追体験を要求しがち。

...という自分の信念を補強する、それっぽい箴言を集めてみる(確証バイアス)

愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。

オットー・フォン・ビスマルク https://ja.wikiquote.org/wiki/%E3%82%AA%E3%83%83%E3%83%88%E3%83%BC%E3%83%BB%E3%83%95%E3%82%A9%E3%83%B3%E3%83%BB%E3%83%93%E3%82%B9%E3%83%9E%E3%83%AB%E3%82%AF


シーザーを理解するためにはシーザーとなる必要はない。 →「追体験できること」は、理解の明証性のために重要であるが、それは意味解明のための絶対条件ではない。

マックス・ヴェーバー ウェーバー「社会学の基礎概念」

⌘+shift+d で"開いているすべてのタブをブックマークとして新しいフォルダに保存する" on Google Chrome

登壇のために Google Chrome 上で開いているタブをすべて閉じて片付けたいが後で一発で戻したい。そんなときに ⌘+shift+d が使える

support.google.com で見つけた。


単純に閉じて再起動すれば? => Google Slides で発表するのでブラウザを立ち上げたままにしたい

Safari などの別ブラウザ使えば? => 普段使いが Chrome なので登壇時も慣れているブラウザを使いたい

「Quipperが実践する、定量データに基づく意思決定と開発」という話を Rails Developer Meetup 2018 Day 3 extreme でしてきました

してきました。

techplay.jp

スライド

データ周りや意思決定の話は専門ではないのであまり主語を大きくして叩かれないようにわりと渋めのタイトルにしました。ちょっと局所的すぎたかもしれません。

トーク

20分のトークは初めてだったので勝手がわからず86枚もスライドを作ってしまいました。直前の脳内練習では18分に収まったものの本番では20分30秒ぐらいになってしまったので練習が足りんなぁ〜と思いました。

質問も ama でいただけていたのに時間内で回答できなかった…ので先ほど web で回答しました。

このように非同期で質問に回答できる仕組みもすばらしい!!

RailsDMについて

実は今回が初参加でした。

とにかく言いたいのが、あれだけのすごいイベントに無料で参加できてしまって本当に良いんですか〜〜

トークが豪華なのは言うまでもなく、ランチもコーヒーもディナーも付いてきて長丁場でも参加できる優しさがありました。オンライン配信とか別会場で同時開催とか、個人の頑張りでできる域を超えている〜〜

来週の StudySapuri Product Meetup も規模はぜんぜん違いますが来場者に満足いただけるよう負けずに頑張ります。

techplay.jp

monorepo 構成の Git repository の sub directory を Netlify にデプロイする

以下のように Git root directory ではなく sub directory にデプロイしたいアプリケーションが存在する場合を想定。

$ tree -L 2
.
├── .git
├── frontend
│   ├── README.md
│   ├── config
│   ├── images.d.ts
│   ├── node_modules
│   ├── package.json
│   ├── public
│   ├── scripts
│   ├── src
│   ├── tsconfig.json
│   ├── tsconfig.prod.json
│   ├── tsconfig.test.json
│   ├── tslint.json
│   └── yarn.lock
├── backend
└── netlify.toml

Deploy context を設定する必要があるので、Git root directory に置く netlify.toml に以下のように記述する。

[build]
  base    = "frontend"
  publish = "frontend/build"
  command = "yarn build"

Netlify の管理画面では Build command も Publish directory も記述しない。

f:id:ohbarye:20180708160355p:plain


いま趣味で作っている Good First Issues を探す web application のフロントエンドはこの方式でデプロイしている。

https://goofi.netlify.com/

github.com