tweeeetyのぶろぐ的めも

アウトプットが少なかったダメな自分をアウトプット<br>\(^o^)/

【node】npmパッケージ nodemonを使ってみるメモ

はじめに

Node.jsの開発時、ソースコードの修正のたびに手動でctrl + c/d -> node main.jsしていると思います。
この一連の監視と再起動を自動で行ってくれるパッケージnodemonを使うメモです。

アジェンダ

  1. nodemonとは
  2. nodemonのインストール
  3. nodemonの実行方法

1. nodemonとは

はじめにでも触れましたが、
nodemonとは、ソースコードの変更を監視し、自動的にnodeコマンドを再起動してくれるnpmパッケージです。

詳細は本家をご確認ください。

2. nodemonのインストール

nodemonのインストールは2通りあります。

2.1. グローバルにインストールする(dependency)
2.2. 開発用だけにインストールする(devDependency)

2.1. グローバルにインストールする(dependency)

$ npm install -g nodemon

2.2. 開発用だけにインストールする(devDependency)

$ npm install --save-dev nodemon

3. nodemonの実行方法

利用もいくつか方法があります。

3.1. グローバルインストールした場合
3.2. 開発用だけにインストールした場合

3.1. グローバルインストールした場合

グローバルにインストールすると、PATHが通るのでコマンドがそのまま使えます。

$ nodemon main.js

3.2. 開発用だけにインストールした場合

開発用にだけインストールした場合、PATHが通っていません。
そのため、実行方法は大きく3通りあります。

  • package.jsonのscriptsを通して実行
  • npx経由で実行
  • 手動実行
package.jsonのscriptsを通して実行

一般的な実行方法です。
package.jsonのscriptsは後述する手動実行をかわりに行ってくれます。

# "start"行を追加
$ vim package.json
-- vim --
  "scripts": {
    "start": "nodemon main.js",
    "test": "echo \"Error: no test specified\" && exit 1"
   }
---------

# 実行
$ node start
npx経由で実行

npmにはnpxというコマンドが同梱されています。
npxを使うと、ローカルにインストールしたnpmパッケージを、npxコマンドだけで実行できるようになります。

$ npx nodemon main.js
手動実行

nodemonの実態は./node_modules/nodemon/bin/nodemon.jsにあります。
また、npmインストールを行うと実行用のファイルも別途生成されています。

# 実態ファイルの確認
$ ls -l ./node_modules/nodemon/bin/nodemon.js
-rwxr-xr-x  1 tweeeety  tweeeety  438 10 26  1985 ./node_modules/nodemon/bin/nodemon.js

$ 実行ファイルの確認
$ ls -l ./node_modules/.bin/nodemon
lrwxr-xr-x  1 tweeeety  tweeeety  25  6 13 03:35 ./node_modules/.bin/nodemon -> ../nodemon/bin/nodemon.js

つまり、実行用ファイルを通して実行する場合は以下のように行います。

$ ./node_modules/.bin/nodemon main.js

参照

終わり

nodemon便利\(^o^)/

【Mac】`Warning: Failed to set locale category LC_XX to en_JP.`というエラー(Warning)が出るとき

はじめに

英語勉強のため、
少しでも英語に触れようとmacの言語設定を英語に変更しました。

そこから、vimを開くと以下のようなエラーが出るようになったので対応メモです。

Warning: Failed to set locale category LC_NUMERIC to en_JP.

目次

  1. なにをしたか
  2. どんなエラーか
  3. どう対応したか
  4. ロケールとは
  5. LANG環境変数
  6. locale

1. なにをしたか

macの言語設定を日本語->英語に変更しました。

以下の順で設定を開きます。

システム環境設定 > 言語と地域

f:id:tweeeety:20200321055410p:plain

希望の言語を「優先する言語」リストの先頭にドラッグします

f:id:tweeeety:20200321055426p:plain

これで再起動後、PCのデフォルト言語が英語に切り替わります。

2. どんなエラーか

GUIで使っている分には特に何も起きていませんでした。

しかし、vimを開こうとすると以下のようなエラーが出るようになりました。

$ vim
Warning: Failed to set locale category LC_NUMERIC to en_JP.
Warning: Failed to set locale category LC_TIME to en_JP.
Warning: Failed to set locale category LC_COLLATE to en_JP.
Warning: Failed to set locale category LC_MONETARY to en_JP.
Warning: Failed to set locale category LC_MESSAGES to en_JP.

エラーと記載してますが、Warningなので気にしなければそのままvimは動作します。 しかし、毎回出るので直したくなります。

3. どう対応したか

対応は簡単で、~/.bash_profileに環境変数LANGを設定するだけです。

# 設定前のlocale確認
# おそらく英語に変えた事で変わってしまったと思われる
$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

$ vim ~/.bash_profile
-- vi編集 --
export LANG=ja_JP.UTF-8
------------

# 設定後のlocale確認
$ locale
LANG="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_CTYPE="UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_ALL=

4. ロケールとは

各言語などの地域情報を「ロケール」と呼びます。
日本の場合現在では「ja_JP.UTF-8」という文字コードです。

このja_JP.UTF-8が何を表しているかというと以下のフォーマットになっています。

言語_国.文字コード

5. LANG環境変数

上記のja_JP.UTF-8ですが、LANG環境変数に設定します。

LANG系の環境変数は、
2. どんなエラーかにも記載したとおりいくつかあります。

LANGLC_ALLは特殊なものとなっています。
LC_ALLが設定された場合は、全てのローカライゼーション系環境変数は必ずその値が使用されます。
LANGの場合は、LC_TIMEなどを個別に設定して上書きが可能です。

6. locale

localeコマンドは現在のロケールを一覧表示します。
locale -aで利用可能なロケール名を表示します。

参考サイト

おわりに

PCを英語に変えたので英語学習に向けて頑張ります\(^o^)/

【書籍】ソフトウェア 開発者 採用ガイド - まとめも

はじめに

この記事は、
「ソフトウェア 開発者 採用ガイド(Joel on Hiring)」
という書籍の自分まとめです。

ソフトウェア開発者採用ガイド
Joel Spolsky
翔泳社
売り上げランキング: 389,465

先日、以下のようなnoteも書いたのでよかったらご参考まで。

目次

  1. 書籍の概要
  2. 書籍の目次
  3. 3単語で表すこの書籍
  4. 書籍まとめ

1. 書籍の概要

https://www.amazon.co.jp/dp/4798115827

Joel SpolskyというMicrosoftで働かれていたソフトウェアエンジニアの方が書かれたエンジニア採用に関する著書です。

ジョエル・スポルスキ(Joel Spolsky、1965年 - )は、アメリカ合衆国のソフトウェアエンジニアで著作家である。ソフトウェア開発について論じたブログであるJoel on Softwareの著者として知られている。1991年から1994年にかけて、Microsoft Excelチームのプログラムマネージャとして活躍し、その後Fog Creek Softwareを創業した。

ref: wiki

エンジニアの採用についておおまかに

  • 優れた開発者を見つける
  • 開発者の見分け方
  • 履歴書について
  • phone screeningについて
  • 面接について

と記載されています。

驚いたのは、記載されたのが2008年なのですが、
2019年に読んで「日本の採用はこれに近づいている気がする」と思った事です。

アメリカでは今日の採用が当たり前のように行われていたことが伺えます。

2. 書籍の目次

amazonからの引用です。

  • 第1章 ソフトウェアにおける高音域
  • 第2章 優れた開発者を見つけるには
  • 第3章 開発者観察ガイド
  • 第4章 履歴書の順序付け
  • 第5章 電話でのふるい分け
  • 第6章 採用面接ゲリラガイド
  • 第7章 最適でないチームを直す
  • 付録 ジョエルテスト

3. 3単語で表すこの書籍

あくまでも所感ですが、この本を読んだ感想を3つの単語で表します。

  • すぐれた開発者
  • 見決めわ目方
  • エッセンス

4. 自分まとめ

4.1 ソフトウェアにおける高音域

Fog Creekでは、
「自分たちが働きたいソフトウェア会社を作る」
ということを目的にしている。

これを成し遂げるプランは次の4つに集約される

最高の仕事環境
 ↓
最高のプログラマ
 ↓
最高のソフトウェア
 ↓
収益!

プログラマのコストをケチるなら、お粗末なソフトウェアを作ることになり、それでいてたいした節約にはならない

1人の際立ったプログラマを5人の凡庸なプログラマで置き換える意味はない。
「遅れたプロジェクトに人を投入するとさらに遅れる」というブルックスの法則のためだ。
チームを可能な限り小さくすることには付加的な利点がある。

また、少数の優れたプログラマの代わりにたくさんの凡庸なプログラマを用意しても優れたプログラマの作り出すものが彼らには決して作れない。

「平均的な」開発者がすごいソフトウェアを作り出す高音域に達することは決してないのだ。 だからソフトウェア開発者であれば最も満足できるキャリアは本物のソフトウェア会社である。

4.2 すぐれたソフトウェア開発者を見つけるには

優れたソフトウェア開発者は、マーケットに出てこない

ソフトウェア開発者を分類すると
無能な人々 >>> しっかりした能力の人 >> 優れた人
となる。

「優れた人々はマーケットには現れない」:

  • 優れたソフトウェア開発者は、その全職歴を通して、平均4回くらいしか職に応募しない
  • 基本的に働きたいところで働くので、彼らが履歴書を送ったり、たくさんの職に応募することはない
  • 無能な人々は、同じように少なかったとしても、何千という職に応募する
  • しっかりした能力の人は、優れた人よりは多いが、無能な人よりは少ない
  • 結果的に、1000通の履歴書のうち30通ほどが検討に値する
そもそも彼らを手に入れることはできるのだろうか

採用を、
「履歴書を集めい、より分ける」
という手順で考えるのではなく、
「勝者を突き止め、接してくるようにし向ける」
という手順で考える必要がある

基本的な方法:

  1. こちらから出向く
  2. インターンシップ
  3. 自分のコミュニティを作る
1. こちらから出向く
  • 雇いたいと思う人がいる場所を考える
  • 足を運ぶ
  • 良い人をみつけたら全力の口説きモード

をおこなう

ただし、大きく汎用的な求人サイトでの広告は避ける。
最初のふるい分けを通るものすらいない

2. インターンシップ

求人マーケットに現れない優れた人をつかみ取る良い方法は、
彼らが求人マーケットなどというものがあることに気づく前に手に入れてしまうこと。
つまり大学にいるときに。

本当に優れたプログラマはしばしばプログラミングを10際のときにはじめる。
法律や医学と違い、大学2,3年で非常に優れたプログラマになっている。
良い大学に行っている若者は、大学にやってくる会社からだけでも良い職の選択肢は十分にあり、大学に来ない会社にわざわざ応募しない。

どのようにやっているか:

  • このプロセスを9月にはじめる
  • 200ほどのコンピュータサイエンス学科に手紙を出す
  • 見つけたコンピュータサイエンス専攻の学生一人ひとりに個人的な手紙を出す
  • インターンシップを知らせ、応募することを個人的に勧める
  • たくさん応募がきたらインターン採用枠1人につき、10人くらいに絞り込み電話面接する
  • 面接を通った2,3人をニューヨークに呼んで直接面接する
  • 実地の時点で採用したい率は非常に高いのでアトラクトモード
  • 送迎リムジン、クールなホテル、会社のお土産や直前インターンのドキュメンタリーを用意する
  • 面接後は、ニューヨークを知ってもらうための滞在も用意する
  • 通るのが1人だったとしてもその通った人が良い印象を持つことが本当に重要
  • 通らなかった人も、いかした会社だと思いながら大学に戻り、どんなに良かったかを友達に話し、聞いた人がまた受けたくなる
  • この時点で正社員として雇いたいかを判断している。だから本物の仕事を与える。
  • インターン中は、特別課外活動や見学旅行も毎週行っている

なんにせよ、本当に雇いたいと思う人について、待つことに意味はない。
卒業後のフルタイムの仕事を早い段階で提示する。
すごく良い条件で。
彼らが大学に戻って友達と情報交換するときに、誰よりも初任給が高い事を知るようにしたいのだ。

これは、面接しか行っていない会社より、より多くの情報を持っている、
良い情報を持っているからこそ、多くの額を喜んで支払える。

アメリカにおいて、この業界のインターンシップには給料が支払われる。
その給料はかなり良い。
週750ドルの給料、住居、昼食、地下鉄のフリーパスを支給している。

フルタイムの社員を1人得るためには、2人のインターンを雇う必要があると計算している。

さらに、高校生をどうにか雇えないかとさえ考えている。
次世代の優れたプログラマとコネクションを築くために。
それがたとえ6年のパイプラインになろうとも。

3. 自分のコミュニティを作る

すぐれた開発者たちの大きなコミュニティを、あなたの会社の周りにどうにかして作り上げること。
ただし、これはかなり難しい

社員による推薦について

優れたソフトウェア開発者をみつけるためのよくあるアドバイスは
会社にいる開発者に聞け
というもの。

しかし、地雷も埋まっていて、新規採用のソースとしては最も弱いと考えている。

ひとつの大きなリスクとして、非競合契約がある。

  • 強制力があると思わなかった
  • 契約書を読む習慣がなかった
  • すでに提示を受け入れ、仕事の初日に初めて契約書を見た

などで気づかなかったとしても強制力があり、しばしば行使されている。

もうひとつのリスクとしては、
採用プロセスで何らかの選考を行っているなら、本当の友達を紹介しない可能性があることだ。
それで不採用になったら友人関係にヒビが入るから。

4.3. 開発者観察ガイド

彼らが職場で好むこと、嫌うことが何なのか、最高の開発者に選ばれるためには何が必要なのか。

個室
  • 個室のほうがステータスが高い
  • キュービクルやその他の共有スペースは落ち着かない
ワークスペースの物質的側面
  • ディスプレイ
  • アーロンチェア
開発者のおもちゃ
  • 最高のコンピュータ
  • 2台の大きなディスプレイ
  • 必要な書籍が自由に買える制度
開発者の社会生活
  • 組織の中でプログラマはどのように扱われているのか?
  • 同僚はどんな人たちか?
  • 独立性と自律性
  • 政治がないこと
何の仕事をしているのか?
  • 開発者を引きつける一番良い方法
    • 彼らに興味深いことをさせること
    • イルマおばさんに会ったときに説明できるくらいシンプル、ないしは有名なこと
    • 多くの開発者は、自分の働く会社の社会的な価値を気にかける
  • 成績上位の新人社員にプロジェクトを選ばせる
  • 必要もなくクールな新技術を使う
    • ビジネスの中心的なアプリでなくても良い
    • 内部的に使われるツールなど
    • 新しいアプリでエキサイティングな新しい言語で書かせる
会社と一体化できるか?
  • 自分の仕事に意味を見出したい
  • 若いプログラマはイデオロギーのある会社に惹かれる
  • 自分の会社の理想主義的な側面を見出し、候補者が間違いなくそれに目を止めるようにする
  • あなたの会社が何を表明しており、どう受け取られているかを考える必要がある

4.4 履歴書の順序付け

履歴書から候補者について多くのことを読み取るのは難しい

そこで3点をポリシーにしている

  • 求人広告を選別的に行い、履歴書の山のノイズを減らす
  • 履歴書はふるい分けして面接しなければならない人の数を減らすだけ
  • 面接する順番を決める。客観的なシステムで点数をつけ構成で一貫的になるようにする
履歴書の順位付けの基準
  • 情熱を持っていること
    • 余暇の時間に課外活動やOSSの貢献を行っている
    • プログラミングが好きであり、新しいテクノロジーの探求にエネルギーを使っている
  • 選んでいること
    • FogCreekが自分の働きたい場所だという一貫した説明を聞きたい
    • 添え状を書くのに時間を使っているという事実は、自信をもっており何千通の会社に応募している事がない
    • こういう候補者は採用を伝えたときに、おそらく受け入れる可能性が高い
  • 英語ができること
    • 自分のアイデアについて明確にコミュニケートできる
    • コンパイラとしかうまくコミュニケートできないプログラマっより実効性が高い
    • ドキュメンテーション、レビュー、会議などで必要
    • 履歴書が整然としているかも重要
    • 整然としていないのは、秩序立てて整理できていない、一般にだらしない
  • 頭がよいこと
    • 高いGPA、高い標準テストスコア、TopCoderなど
  • 選ばれていること
    • 過去に非常に選別的なプロセスを通り抜けた証拠
    • 応募者の30%未満しか受け入れてない大学、難関採用プロセスの会社で働いてたなど
  • 本格的であること
    • 履歴書はプログラマを判定する方法としてはとても貧弱
    • 難しいテクノロジーは上のほうへ上がる傾向にある
  • 多様性をもたらすこと
    • 十分に違ったバックグラウンドを持つ人々を特に求めている
    • 例えば、エンタープライズでの経験はインターネットチームに有用な多様性をもたらす
    • バックグラウンドの多様性は、チームが異なった解放を見出だせる可能性が高くなる

これらは採用の基準ではない。
大きな履歴書の山を並べ直すための客観的で公正な方法というだけのことである。

このテストで点数が低いが優秀な人や、点数が高いがへぼなプログラマーもいる。

履歴書が貧弱なら、もっと関門を追加する事はできないか?

リクルーターが感じる誘惑のひとつに、
応募プロセスに余分な関門を追加する
というものがある。

応募数を減らす点では機能するが、応募の質を改善するという点ではうまくいかない。
良いプログラマも追い払ってしまうことになる。

特定のテクノロジーの経験を求めないこと

最高のプログラマーにとって、リクルーターに対して頭にくるところは、
彼らがキーワードやバズワードに病的に執着していること

SmalltalkとPythonの深い経験をもつがRubyを聞いたこともない人は、
Rubyの本を一度読んだ事がある人よりも成功する見込みがずっと高い。

4.5. 電話でのふるい分け

電話でのふるい分けには、通常の実地の面接と違った利点がある。

  • 安上がりなこと
  • 1時間未満で履歴書の上では実に素晴らしいと思う人の半分を削る事ができる
  • それがよりフェアに行える

電話での面接は3つのパートからなっている

  1. 候補者に職歴、自身について説明してもらう
  2. 技術的な質問をする
  3. 私のことを質問させる
1. 候補者に職歴、自身について説明してもらう

そうする意図は、彼らをくつろがせ、気分を楽にして緊張を取り除き、彼らに自分を表現したいような仕方で表現させることだ。

この段階では、候補者が問題解決者、物事を成し遂げるタイプの人であることを示すものを探す。
また、情熱も探す。

このパートでは、2つの方面に掘り下げる

テクノロジー:

これこれのプロジェクトをやったという場合、以下の点について詳しく質問する

  • 彼らが使ったテクノロジー
  • それをどう使ったのか
  • 彼らが具体的に果たした役割

自分でなにをやっているかわかってない人、話を作っている人、役割を誇張している人を見破れる。

政治:

履歴書にある過去に勤めた会社には常に物語がある。それを詳しく掘り下げる。

  • 過去に困難な問題にどう対処してきたかという物語
  • 抵抗に直面しても物事を成し遂げてきたような人
  • 体制に挑戦し、反対を乗り越え、何かを実現したような人
2. 技術的な質問をする

理想的な質問は、

  • 候補者が使った経験があってどういうものなのかは知っているが
  • 自分で実装したことはありそうにないようなもの

目的としているのは、必ずしも最良の答えを見つけ出す事ではない。

3. 私のことを質問させる

この時点では、すでにその人が実地に勧めるかを判断している

だから、このパートでは自分のほうが面接をされ、
候補者はFogCrreekを売り込まれるという形を取る。

面接プロセスは、候補者が私達のところで働きたいと思うかを判断する場でもある。

ただし、質問によっては、
webサイトを5分も調べればわかるような下調べさえ面接前にしていないと、
頭の良さや物事を成し遂げる能力に対する信用を失う。

4.6. 採用面接ゲリラガイド

ソフトウェアプロジェクトにとって一番重要なのは人なんだと
リップサービスはするけれど、それについて何ができるかとなると誰にもよくわからない。

良いプログラマを手に入れたければ、最初に正しくやらなければならないのは適格なプログラマを雇うという事だ。

人を雇うとき、上級スタッフが候補者を落とすのは認めてもいいと思うが、
下級スタッフの1人が気に入らなかったというだけで誰かを落とそうとは思わない。

面接では、3種類の人たちを見分けることになる。

  • 極端な無知な人
  • なにかに貢献できそうに見える人
  • スーパースターな人

「なにかに貢献できそうに見える人」は、迷ったら不採用だ。

短期的な痛みの解決と引き換えに、ずっと長く続く痛みを抱え込むことになる。

「いいかもしれないけど、わからない」とは決して言わないこと。
もしわからないならそれは不採用を意味する。

どっちつかずのものはすべて機械的に「ノー」に置き換えても差し支えない。

それは
良い候補者を落とすほうが、まずい候補者を採用するよりもずっとまし
だからだ。

まずい候補者は:

  • たくさんのお金と労力がかかる
    • 彼らのバグを直すために他の人の時間が奪われる
  • 解雇するには何ヶ月もかかり悪魔のように難しい可能性がある
  • まずい社員は良い社員のやる気をくじく
  • プログラマとしてまずくとも人間として本当にいいやつの場合がある
    • あなたは彼らを解雇するのは忍びない、または、みながうんざりする可能性がある

ひとたび誰かを面接するとなったら、
ドアの外には900人の候補者が列をなしているというフリをする。
基準を下げてはいけない。

誰を採用すべきかをどうやって判断するか

判断は2点しかない

  1. 頭がよく
  2. 物事を成し遂げる

頭がよく、成し遂げない人は以下のような人がいる

  • 博士号をもっていて大企業で働いている
  • スケジュールどおりに出荷するよりアカデミックなことに重きをおく
  • 頭は良いが役に立たない

頭は悪いが物事を成し遂げる人は以下のような人がいる

  • 考えなしに馬鹿なことをやり誰か他の人がその後始末をする羽目になる
  • 優れた人の時間を奪う

面接で頭の良さをは以下のポイントで見出す

  • 何度も繰り返し説明せずに済む
  • 候補者がいかに頭が良いかを示せる状況を作る
悪い面接者
  • 自慢屋
    • 候補者に「ええ、そうですね」と言うくらいの時間しかなくなる
  • クイズショー
    • 頭が良い=「たくさんの事実を知っている」だと思いこんでいる
    • 雑学問題をひたすら出し続ける
    • 15秒もあればネットで調べられるものは意味がない

特定のスキルセットではなく、資質を持った人を雇いたいものなのだ。 仕事に持ち込むどんなスキルセットも2年もすれば技術的に古くなってしまうだろう。

一般に、ある人について最も多くのことを知ることができる方法は、
その人に話をさせることだ。
自由回答形式の質問と問題を与える。

面接前に用意するプラン

面接の前に面接で使うプランを用意すると良い

  1. イントロダクション
  2. 候補者の最近のプロジェクト
  3. 簡単なプログラミングの質問
  4. ポインタ/再帰の質問
  5. 答えに満足しているか?
  6. 質問は?
1. イントロダクション

これは候補者をリラックスさせるためのものだ。

  • フライトはどうだったか
  • 自分は誰で面接がどう進むか
2. 候補者の最近のプロジェクト

最近のプロジェクトについての質問をする

自由回答形式の質問をし、耳を傾け、相手が詰まっているときは
「それについてもう少し聞かせて」と言う

自由回答形式で探すもの

  • 情熱
    • プロジェクトに対して情熱的
    • 情熱的に否定的であるというのも良い兆候
    • それについて話しているときに面接中という事を忘れることもあるくらい
  • 物事をよく説明しようと気を使う
    • 普通の人が理解できるように説明できない候補者は落とす
      • 「ちょっと練習だと思って祖母にわかるように説明してもらえないかな?」と聞く
  • リーダシップの兆候
    • チームで行った成果なら「あなたは何をしたの?」と聞く
    • 物事を成し遂げるか知る唯一の方法は、過去に物事を成し遂げたか見ること
3. 簡単なプログラミングの質問

仕事をしているプログラマであれば1分くらいで解けるはずの問題を出す。
みんな問題を解くことは解くが、特のにかかる時間に大きな差がある。

基本的なコンセプトが考えるまでもないというくらい簡単に思えるのでなければ、
大きなコンセプトを把握することが難しい。

4. ポインタ/再帰の質問

面接の形式が、
表面的には候補者がただホワイトボードにコードを書くだけというものであっても、
ここでの本当の目的は、そのコードについて会話をすること

  • なんでそんなふうにしたの?
  • そのアルゴリズムの特性はどういうもの?
  • 何か忘れてない?
  • バグがどこにあるかわかる?

これは、難しすぎる問題でも構わない。
候補者が手をつけられるチャンスがありさえすれば良い。
進めながら小さなヒントや足がかりは喜んで出す。
ただし、ヒントはgoogleで見つけられるような雑学問題の答えだ。

5. 答えに満足しているか?

ほんとんどの場合、一発で書いたコードにはバグがある。

プログラマは誰でもミスをする。
そのこと自体に悪いことはなにもない。
ただ、それを見つけられる必要がある。

そのため、追加で以下のようなことを質問してみる

  • 「そのコードで満足している?」
  • 「OK、じゃあバグはどこにあるかな?」

極稀に、最初からバグがまったくないコードを書く候補者もいるが、
「このコードにはバグがあるよ」と言ってみる。

コードを注意深く見直し、コードの正しさを厳格に示し、
礼儀正しいながらも毅然とおしてコードは完璧だと断言するかを見ることもできる。

6. 質問は?

この時点では、どんな質問をされようが気にかけない。
すでに心を決めている場合が多い。

候補者に対して、会社と仕事を売り込むのに使っている。
良い候補者でもまずい候補者であっても、会社のことを好きになり、良い印象を持って帰って欲しいと思う。

面接のあと

候補者について決断を下すのに最適な時間は、面接が終わった3分後。
時が経つほど記憶は薄れていく。

面接者には、面接のあと即座にフィードバックを返すよう求めている。
また、これの納期は15分後としている。

決断するのに困難を感じるなら簡単な方法は不採用にすればいい。
確信が持てない人は単に雇わないこと。

どうすれば最高の人を雇えるのか

諦めないこと。
優れた人は平均的な人よりはるかに価値がある。

プログラミングにおいては3-10倍の生産性が、たった20-30%の余分なコストで手に入れられる。

4.7. 最適でないチームを直す

あなたは、チームメンバーが次の3つのどれかを把握する必要がある

  1. 優れた開発者
  2. 改善すべき点のある開発者
  3. 望みのない開発者

新しいマネージャになった人がこれをやるための一番手っ取り早い方法は、同僚の評価を聞くことだ。
匿名を約束した上で、この3つのどれに当てはまるかをそれぞれ聞く。

働きの悪い者の解雇は必ずしもモラルを損なわない

マネージャが働きの悪い者を取り除くことを恐れるのは、それによってチームのモラルが下がるのを懸念するためだ。
チームリーダの究極的なゴールはチームのパフォーマンスを引き上げることだ。

パフォーマンスの改善

マネージャは、具体的で、現実的で、達成可能なゴールを設定し、彼らがどこへ向かうべきかを理解するのを助ける必要がある。
これはマネジメントのコーチングの側面だ。

マネジメント法

何かを率いようとするときに直面する主たる問題は、
みんなを同じ方向に進ませなくちゃいけないということだ。
これは実際には「他の人を思ったとおりに動かす」ということを体裁良く言っているにすぎない。

この場合のアプローチ方法が3つある。

  • 指揮統制法
  • 入門経済学法
  • 一体化法

マネジメントの本当の秘訣は、達成しようとしているゴールにみんなを一体化させることで、一体化法が向いている。

そのためにとても満足している方法は食事を一緒にすることだ。

家族のように感じられる結束したチームを作ることが必要とされる。
それによって同僚に対する誠実さと責任をみんなが持つようになる。

おわりに

リファラルというと、なんとなく「声をかける採用でしょ。知ってる」となりがちです。
しかし、実際のところ、かなりの労力が必要だという事が本書を読むとわかります。

最後に、本書で印象に残った言葉を綴っておわりにします

「これからの採用はお金をかけずに、汗をかく」

Enjoy Hiring!!

補足

このまとめについての補足です。

  • 202001時点のまとめです
  • あくまでも僕自信が参考になったポイントです
  • 汎用的なポイントとはズレる可能性があります

【JIRA】Jira Cloudでslackを連携させるメモ

はじめに

JIRAとSlackを連携させて、Jiraをより便利に使おうというメモです

アジェンダ

  1. Jira Cloud for Slackとは
  2. Jira - Slack integrationのながれ
  3. SlackにJira Cloudアプリを追加する
  4. Jiraにてintegrationを作成する
  5. Jiraにてintegration設定する
  6. Jiraでticket発行してみる

1. Jira Cloud for Slackとは

まんまではありますが、Jiratとslackの連携をするアプリです。

なにができるか

以下のようなことができます

  • Jiraでのissueオペレーション
    • ticket発行・更新時にslackに通知する
    • assignee追加・更新時にslackに通知する
  • Slackでのオペレーション
    • slash commandsでチケットを発行する
    • slack上でassigneeを変更する

どこにあるか

それぞれの場所を確認してみます

jira

jiraではprojectごとにintegrationを設定します。
projectページのProject settingsから設定を開きます
f:id:tweeeety:20191107184753p:plain

設定ページで左サイドバーの下のほうにあるSlack integrationを開きます f:id:tweeeety:20191107184837p:plain

このページで設定しますが、
SlackとのConnectionをしないとそもそも選ぶものもなく、
Addができません f:id:tweeeety:20191107184854p:plain

slack

workspaceにwebでアクセスしConfigure appsを開きます。
appsの検索でjiraと打てばjira cloudが出てきます。
f:id:tweeeety:20191107184915p:plain

2. Jira - Slack integrationのながれ

integrationの設定を行います。
公式サイトにも記載してますのでご参考ください
* Jira Cloud for Slack

integrationの流れは主に以下の流れで行います

  • SlackにJira Cloudアプリを追加する
  • Jiraにてintegrationを作成する
  • Jiraにてintegration設定する

3. SlackにJira Cloudアプリを追加する

公式にも記載のある以下のを開きます

https://jira-slack-integration.prod.atl-paas.net/api/slack/login

利用想定のworkspaceが選択された状態を確認し、Allowを押します。
f:id:tweeeety:20191107184953p:plain

Log inを押します f:id:tweeeety:20191107185012p:plain

G Suiteなどを利用していればSNS 認証でログインしてください f:id:tweeeety:20191107185026p:plain

ログインが成功するとslackに通知が来ます f:id:tweeeety:20191107185040p:plain

Dialogは左: jiraのProject右: slackのchannelとなっています。
選択してconnectを押します。
f:id:tweeeety:20191107185106p:plain

これにて成功です!! f:id:tweeeety:20191107185118p:plain

4. Jiraにてintegrationを作成する

Projectページ > Project settings > Slack integration を開きます。

今度はTeamsにslackのworkspaceが選択できるようになっています。
f:id:tweeeety:20191107185134p:plain

workspaceとchannelを選択してaddするとChannel Subscriptionsにintegrationが追加されます。 f:id:tweeeety:20191107185203p:plain

5. Jiraにてintegration設定する

Channel SubscriptionsのEditから細かい設定が行えます。
f:id:tweeeety:20191107185218p:plain

6. Jiraでticket発行してみる

Jiraでticketを発行すると設定したchannleに以下のように投稿されます f:id:tweeeety:20191107185230p:plain

また、Slack上の からAssignを変更したりも可能です f:id:tweeeety:20191107185238p:plain

おわり

Jiraとslackの連携は昔はもっと大変なイメージがありました。

いまはとても簡単になってます!\(^o^)/

【git】submodule updateでfailed & 毎回パスワード聞かれる問題

はじめに

とあるrepositoryにsubmoduleを複数使っていて、
git submodule updateをしたかったのですが
以下の2つで困ったのでメモ

  • 毎回パスワードを聞かれる
  • ID/pass入力でfatal: Authentication failedしてしまう

アジェンダ

  1. 起こったこと
  2. 対応したこと

1. 起こったこと

冒頭に記載したまんまですが、

  • 毎回パスワードを聞かれる
  • ID/pass入力でfatal: Authentication failedしてしまう

が起こっていました。

このときの状態

このときの状態は以下のようになっていました。

$ vim .gitmodules
-- vi --
[submodule "template/a"]
  path = template/a
  url = https://github.com/hoge/template-a.git
[submodule "template/b"]
  path = template/b
  url = https://github.com/hoge/template-b.git
[submodule "template/c"]
  path = template/c
  url = https://github.com/hoge/template-c.git
--------

実行したとき

3回ID/passが聞かれた上にfailedしました。

$ git submodule update
Cloning into '/Users/tweeeety/github/any-repos/template/a'...
Username for 'https://github.com': tweeeety
Password for 'https://tweeeety@github.com':
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/hoge/template-a.git/'
fatal: clone of 'https://github.com/hoge/template-a.git' into submodule path '/users/tweeeety/github/mercari/any-repos/template/a' failed
failed to clone 'template/a'. Retry scheduled
Cloning into '/Users/tweeeety/github/mercari/any-repos/template/a'...

~ 省略 ~

2. 対応したこと

対応としては.gitmodulesのurl指定をhttps指定からssh指定に変えました。

こんな感じですね

$ git diff .gitmodules

--- a/.gitmodules
+++ b/.gitmodules

 [submodule "template/a"]
        path = template/a
-       url = https://github.com/hoge/template-a.git
+       url = git@github.com:hoge/template-a.git
 [submodule "template/b"]
        path = template/b
-       url = https://github.com/hoge/template-b.git
+       url = git@github.com:hoge/template-b.git
 [submodule "template/c"]
        path = template/c
-       url = https://github.com/hoge/template-c.git
+       url = git@github.com:hoge/template-c.git

.git/config 内のsubmoduleの向き先は
この時点では変わらないので以下を実行します

$ git submodule sync

で、実行してみるとうまくいきましたとさ

$ git submodule update
Cloning into '/Users/tweeeety/github/any-repos/template/a'...
Cloning into '/Users/tweeeety/github/any-repos/template/b'...
Cloning into '/Users/tweeeety/github/any-repos/template/c'...
Submodule path 'template/a': checked out 'xxxxxxxxxxae935311265746382d1b54b4e2ab0f'
Submodule path 'template/b': checked out 'xxxxxxxxxx2b91a43b8a318f491348aa62b5306f'
Submodule path 'template/c': checked out 'xxxxxxxxxxa378276a71869ef3a63cdb3bb7b2c9'

おわり

httpsだとなんでダメなんや...
というところはあやふやにしてしまいましたが、
一旦次行きたいのでメモのみで!!\(^o^)/

【go】goenvとdirenvとGo Modulesとで新しいgo環境をつくる

はじめに

Golang環境は、職場でも数年利用していました。 Macが新しくなった + 日に日に新しくなっているのでこれを機にlocal環境を作りなおしてみるメモです。

アジェンダ

  1. 今回の構成
  2. goenvでgoいれる
  3. direnvでlocal設定する
  4. go modでpackage管理する
  5. 実行してみる

1. 今回の構成

場所はどこでも良いのですが、
以下にsampleをおくと仮定して進めます。

$ cd $HOME/sample

$ pwd
$HOME/sample

2. goenvでgoいれる

goenvは、go言語のバージョンを管理するものです。
rbenvやnodebrewを使ってる人には名前を見たらすぐわかりますね!

goenvのinstall

$ go version
go version go1.12.4 darwin/amd64

$ brew install goenv

$ goenv versions
* system (set by /Users/tweeeety/.goenv/version)

goenvの設定

$ vim ~/.bashrc
-- 追記 --
# for goenv
export GOENV_ROOT="$HOME/.goenv"
export PATH="$GOENV_ROOT/bin:$PATH"
eval "$(goenv init -)"
----------

goenvでgoの任意のversionをインストール

$ goenv install --list
Available versions:
 1.2.2
 1.3.0
 ~ 省略 ~ 
 1.11.3
 1.11.4
 1.12beta1

$ goenv install 1.11.4
Downloading go1.11.4.darwin-amd64.tar.gz...
-> https://dl.google.com/go/go1.11.4.darwin-amd64.tar.gz
Installing Go Darwin 64bit 1.11.4...
Installed Go Darwin 64bit 1.11.4 to /Users/tweeeety/.goenv/versions/1.11.4

# $HOME/sample配下を1.11.4にする
$ goenv local 1.11.4

$ ls -al
total 8
drwxr-xr-x  3 tweeeety  tweeeety   96  6 23 02:47 .
drwxr-xr-x  6 tweeeety  tweeeety  192  6 23 02:46 ..
-rw-r--r--  1 tweeeety  tweeeety    7  6 23 02:47 .go-version

$ cat .go-version
1.11.4

2. direnvでlocal設定する

direnvのinstall

direnvのinstallは以下をご参考ください

direnvの設定

$ pwd
$HOME/sample

$ direnv edit .
-- vi追記 --
export GO111MODULE=on
export GOPATH=$PWD/go
------------

# 念の為
$ direnv allow

3. go modでpackage管理する

package管理には
これまでglideやらdepやらがいましたが、
これからはGo Modulesらしいので使ってみます。

go mod initでgo.modを作る

go 1.12からはデフォルトだけど、
go 1.11ではexport GO111MODULE=onとすることで使用できるようです。

今回は、上記のdirenvにて、
特定のdirに対してはexportするように設定したものですね。

go mod init helloを打つと、
go.modというファイルができます。

$ go mod init hello
go: creating new go.mod: module hello

hello.goを作る

rsc.io/quoteは、 Go Modulesの説明のために作られたパッケージのようなのでそれを使います。

package main

import (
    "fmt"

    "rsc.io/quote"
)

func main() {
    fmt.Println(quote.Hello())
}

go buildでpackageのinstallも行う

go buildを打つと利用しているpackageをinstallまでしてくれます。

$ go build
go: finding rsc.io/quote v1.5.2
go: downloading rsc.io/quote v1.5.2
go: extracting rsc.io/quote v1.5.2
go: finding rsc.io/sampler v1.3.0
go: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
go: downloading rsc.io/sampler v1.3.0
go: extracting rsc.io/sampler v1.3.0
go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
go: extracting golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c

$ cat go.mod
module hello

go 1.12

require rsc.io/quote v1.5.2

また、この時点で以下のような構成になっています

$ pws
$HOME/sample

$ tree . -L 4
.
├── go
│   └── pkg
│       └── mod
│           ├── cache
│           ├── golang.org
│           └── rsc.io
├── go.mod
├── go.sum
├── hello
└── hello.go

6 directories, 4 files

4. 実行してみる

$ go run hello
こんにちは世界。

無事、実行できました!

おわり

Go Modules便利\(^o^)/

【node】pyenvでpython3使ってたらnpm install sleep --save-devで`gyp ERR! configure error`と怒られたメモ

はじめに

nodeのネタではあるんですが、
pythonでエラーというパターン

悲しみ...

なにがやりたいか

nodeでsleepが使いたかっただけです。
つまり以下が実行したかっただけです

$ npm install sleep --save-dev

どんなエラーか

$ npm install sleep --save-dev

> sleep@6.1.0 install /Users/tweeeety/sample/node_modules/sleep
> node-gyp rebuild

gyp ERR! configure error
gyp ERR! stack Error: Command failed: /Users/tweeeety/.pyenv/shims/python -c import sys; print "%s.%s.%s" % sys.version_info[:3];

~ 省略 ~ 

原因

原因はpython3系なことが原因のようです。

ちょっと前にわけあって
たしかにpyenvでpython3にしていた...

$ python --version
Python 3.7.2

$ pyenv versions
  system
* 3.7.2 (set by /Users/tweeeety/.pyenv/version)

どう対応するか

ここまで書いていると言わずもがなですが、
pyenvでsystem pythonに戻してからnpm installしなおします

$ pyenv global system
$ pyenv versions
* system (set by /Users/tweeeety/.pyenv/version)
  3.7.2

$ npm install sleep --save-dev

> sleep@6.1.0 install /Users/tweeeety/sample/node_modules/sleep
> node-gyp rebuild

  CXX(target) Release/obj.target/node_sleep/module_init.o
  CXX(target) Release/obj.target/node_sleep/sleep_cpp11.o
  CXX(target) Release/obj.target/node_sleep/sleep_posix.o
  CXX(target) Release/obj.target/node_sleep/sleep_win.o
  SOLINK_MODULE(target) Release/node_sleep.node
npm WARN search_repository@1.0.0 No description
npm WARN search_repository@1.0.0 No repository field.

+ sleep@6.1.0
added 1 package from 1 contributor and audited 65 packages in 4.001s
found 0 vulnerabilities

おわり

pythonでnpmがエラーになるみたいな感じだと
最初はめっちゃわかりにくい...

pyenv localの方で設定すれば良かった説もありますが><