See the Elephant

1992生まれのプログラマが書くエンジニアブログ

iTerm2 v3 & NeoVimで<C-h>にマッピングできない時

技術 日記

環境

 * Mac book air 2013 el capitan
 * iTerm2 build 3.0.7
 * NeoVim 0.1.4

iTerm2 v3にアップグレードした後, vim で <C-h> にマッピングできなかった.

ここを参考にした.
http://www.geoffcorey.com/2015/10/iterm2-c-h-key-fixed-for-vim-and-neovim/

// in iTerm2
Edit -> Preferences -> Keys
Press +
Press Ctrl+h as Keyboard Shortcut
Choose Send Escape Sequence as Action
Type [104;5u for Esc+

理由はiTerm2.
iTerm2側で<C-h>をエスケープしないと, Vim側では<BS>とみなされるらしい.

Tips

:verbose nmap <C-h>でキーマップしている設定ファイルのパスが表示されるので,
意図するマッピングが行えているか視覚的に確認できる. 便利.

1を足す

日記

就職活動中に書いた「自己分析という...強みを言語化することは大切だと思う」から5ヶ月も経っていてとても驚いている. この5ヶ月は自分にとって大きな変化があった月日だった. 就職先はベンチャー企業に決めた. それは5/11のこと. そのあと, 2年以上付き合った彼女とはきっぱり別れた. そのあと, 自分の好きな物, 本当に必要なもの以外は全て捨てた. 1度生まれ変わるつもりで自分を見つめ直した. 心の底から大学4年, 修士1年で沈み込んでいた自分を再構築したかった.

就職先はVOYAGE GROUPに決めた. 常にスピードと結果を求められる環境にいたい, チームでものづくりを成し遂げたい, 時代の先端に近づいていたい. そんな思いを胸に入社を決めた. NTTの看板を持つ子会社を蹴り, ベンチャー起業に入る. 選択の正否は自分自身でもわからないし, それは僕自身の今後の選択による.

今は, VOYAGE GROUPの夏インターン「Treasure」にTAとして参加している. インターン生のレベルは高く, 自分では教えられない知らない部分が多い. WEBの仕組み, DBの設計, セキュリティ, UIの設計と実装, コーディング, チームビルディング. 知らないことがあまりにも多い. 自分が勉強し少しだけ自信を持っていたものは人にとって当たり前の知識であることが日々分かる. そして, インターン生は自分が知らない知識を共有しあってさらに差がついていく. 同期もインターン生もレベルが高く, 彼らに価値を提供できていない自分は大丈夫なのだろうか. 職業プログラマとしてやっていけるのだろうか. 日々不安は尽きない.

だけど, そこに落ち込む必要もないのだろう. 僕が尊敬する方々の言葉を借りる.

  • 堀江貴文氏 : 「まずは掛け算でなく足し算をする. みんな最初から掛け算を考える. そうではなく, 地道に1ずつ足していく. 0に何を掛けても変わらない. 足して数が大きくなってから掛け算をすればいい」
  • 鈴木健太氏 : 「職業プログラマとして仕事を始めてから4年ほど経って、習慣にしていることがある。それは平常であり続けて、毎日少しずつ歩を進めることだ。」
  • 鈴木一朗氏 : 「小さいことを積み重ねるのが、とんでもないところへ行くただひとつの道だと思っています。」

この5ヶ月間, Rails, Go, Webの勉強, チームビルド, 研究, 掃除におしゃれと1日1日を着実に変化させている. コードはほぼ必ず毎日書く. 最新のニュースを必ず読む. 周りの人間に感謝し価値を出す. 毎日継続することで見えないものが見えてくる. 感じ取れるものが増えていく. 自分ごととして捉えられる.

現状の自分の能力ではきっと足りていない. 誰の足元にも及ばない. だけど, 1日1日自分の限界を少しでもいいから越える. それで少しずつ強くなる. 間違っていない. 自信を持っていこう.

「自己分析という...強みを言語化することは大切だと思う」を読んで思ったことをツラツラと

日記

昨年7月からお世話になっている株式会社Basicの人事

新田さんのブログを読んで思うことがあったのでこの記事を書こうと思います.

その前に, 僕の就活状況を話しておきます.

修士1年生

2015年

  • 学内就職イベント(サポーターズ)のイベントでBasic新田さんと出会う

  • Basicさんで2daysインターン

2016年

  • 年明け, ひとまず就活セミナーに参加する

  • ベンチャー7社にエントリー

  • 1月に2社からお祈りメール(落選)

  • 3/28現在, 3社から内定をもらう.

  • まだ2社は選考中

  • 飽きずにエントリー出してる

現在も就活続行中

就活をやっていると出くわす強敵３ワード.

  • 「自己分析」大事ですよ !!
  • 「あなたの強みはなんですか?」
  • 「3~5年後の目標はなんですか?」

「自己分析」大事ですよ!

既に就職している先輩, 友達, セミナーの講師に話を聞くと皆が口をそろえて言います.

またか... と思いつつ、とはいえ、ひとまず一応話は聞いてみるんですよね.

そして家に帰ってきて落ち着いてから

「自己分析」って結局なんなの???ワカラン（●｀ε´●）

ってなるのが大抵の場合オチです.

そして, googleに「自己分析 やり方」みたいなqueryを投げるんですよね(笑)

僕もやりましたが...自動判断でわかったら苦労しないです...

自己分析のやり方は誰も教えてくれない

上記のような状況は当然だと思うんですよね.
これまでの人生で自分を分析したことなんてないし, そもそも誰も分析のやり方を教えてくれないんだもん.

そもそも僕らが知りたいのは「大事かどうか」じゃなくて
「どうやってやるの」なんですよね...

じゃどうすんのよ(´・ω・｀)

ってことに答えてくれる記事が以下の記事.

自己分析という言葉がいいかどうかはさておき、強みを言語化することは大切だと思う [Basic 人事HR]

僕がこの4ヶ月強の就職活動で感じたこととが そのまま言語化されていたので, ホントに頷きながら読んでいました(笑)

「自分の強み」とは「自分の好きなこと」である

この記事で僕が特に共感した部分はここ.

 1. 強みとは、「経験」から生まれる
 2. 強みとは、「好きなこと」から生まれる
 3. 強みとは、「得意なこと」から生まれる

ブログのタイトルを借りて当てはめてみると

 1. 「経験」を言語化することは大切だと思う
 2. 「好きなこと」を言語化することは大切だと思う
 3. 「得意なこと」を言語化することは大切だと思う

つまり, 自分の強みを知るためには

自分の好きなこと/経験をトコトン言語化する

ことが一番近道なんですよ.

実際, 僕は面接中に自分の趣味のことばっかり話しています.
「太鼓(獅子舞), ヘッドホン, ウィスキー, Webアプリ(サークル), 言語処理, 時々彼女」みたいな感じ.

でも, 自分でもそれでいいと思ってるんですよね.

自分が好きなことを"面白そうに"語れる奴は強い

人間20年近く生きていれば1つや2つ長く続けていることがあると思います.

そして, 面接の時に扱う「好きなこと」は正直なんでもいいのかなと思います.

例え社会的にあまり印象の良くないパチンコだってゲームだって話し方次第ではその人の「強み」になると思うんです.

もし仮に, 僕の趣味がゲームしかないのであれば記事末尾のようにESを書くでしょう.

たかがゲームの話でも, 以下のように「強み」が取り出せますよね.

 - 他人と同じ環境下で自身の力を試し, 試行錯誤で育てる力
 - 勝つために様々な方法で取り組む力(ビデオ撮影, チーム共有)
 - 1人ではなくチームで成果を出すことに喜びを得ること

上記は例ですが,
本面接では太鼓のことを中心に話していました.

 - 地元の祭りで2日間計20時間近く太鼓を叩く
 - 手も体もぼろぼろになる(握力がなくなる)
   - バチと手をバンテージで繋げて握力がバチが飛ばないようにする
 - 例え痛くとも太鼓は1人しか演奏しないので絶対にミスできない
 - お金も交通費しか支給されない
 - だけど毎年必ず参加する

それはその環境が楽しいから痛みは関係ない. ひとえに楽しい.

一度自分の好きなことを文章に起こすことで, 自分のやってきた取り組みが見えるようになるんですよね.

 - 「好きなことを言語化すること」で「好きな理由」が見えてくる
 - 「好きな理由」が見えることで「取り組み」が見えてくる
 - 「取り組み」が見えることで「取り組んだ姿勢」が見えてくる
 - 「取り組んだ姿勢」が「その人固有の強み」になる

企業の方々はこういった「取り組んだ姿勢」を見るために, 僕にサークルや趣味, 研究内容を質問してくるのだと思います.

その姿勢から以下の2つを見ているのでしょう.

  • 「僕がどのような思想/過程で形成されてきたか」
  • 「僕が何を大切にしているか」

僕の場合は, 痛くても辛くても楽しい環境の方が大切です.

上記のように考えてからは, 僕は自分が好きなこと, やってきたことを堂々と話して堂々とオチてきました笑

「僕が大切にしていること」と「会社が大切にしていること」に相違がある場合は話に興味を持ってくれません. それは面接中でも面接官の態度から顕著にわかります.

僕の好きなことを話して, 興味を持ってくれない企業は僕には多分合っていないでしょう. 逆に自分が好きなことを話して内定をくれた企業は,「僕の生き様」を認めてくれたんだなーと思っています.

とはいえ, 誰にも理解/共感してもらえないと意味が無いです!!!

結論ファースト, かつ, 面白く!!

上記を守って書く/話すことは大切です(ゲームの例は正直面白くないですねorz).

やはり,

自分の趣味を語れる = 自分の強みを言語化できている = 自分の強みを理解している

と言えるのかな, と思います.

「3~5年後の目標はなんですか?」

これもまた難しい問題ですよね.
生きる目標があまり無い僕にとっては辛い質問です....

とはいえ, 何も考えてないわけではないし,幸せになりたいと思って生きています.

やりたいことなんかないけど、しあわせでいたい人の話

新田さんブログから参照...

僕も典型的な価値観型で, 基本的には 「なんか最近オレが思う幸せと現実が違う」って気づくと燃えるタイプ. 理想と現実の差分が熱量に変わるタイプの人間です.

ってことは, 自分の「理想の幸せ」を定義すれば, 自ずと理想と現実の差分「課題」が出てくる. それをクリアするための通過点「目標」が設定されるよね.

って論法で目標を作り上げればいい.

夢がないんじゃなくて近眼なだけ

僕の場合, できてないこと「課題」を列挙すると, やるべきこと「目標」が見えるようになったんですよね.

  • 外国人と話せない / リファレンスを辞書繰って読むのめんどくさい
    • 英語話せるようになりたい
  • 自分が先輩になった途端, 僕が好きだった環境をサークルで実現できていないことに気づいた
    • 後輩にやりがいを持ってもらって参加できる環境を作ろう
  • 今まで生きてきて, 誰かに「本気で」喜んでもらっていない
    • 僕の能力で誰かを幸せに出来る職業に就きたい
  • 新潟の片田舎で収まりたくない
    • 東京で働こう

でも, このままじゃただただ「目標」なんですよね.

目標を掲げるのはいいんですが, プレッシャーに感じられて得てして楽しくない.

だったら, 楽しくすればいいじゃん !!! と, 楽しさをかけてみたら「夢」になることに記事を書いていて発見しました.

  • 英語話せるようになりたい × 人と話すのが楽しい = 世界の人と話せるようになる

  • 後輩にやりがい × 自分を認めてもらう嬉しさ = 後輩と信頼関係が生まれる

  • 僕の能力で誰かを幸せに出来る職業 ×　試行錯誤して作るのが好き = エンジニアリング!

  • 東京で働こう × 友達も多くいる = 公私が充実する

僕の夢は,

「世界の人と話せる後輩に信頼された公私の充実した東京在住エンジニア」

なんですねーｗ はじめて言語化したけど...確かにとても僕の理想に近いかも(笑)

ここまで考えられれば３〜５年後の目標立てるのは, そんなに難しいことでもないのかなと思います.

ちなみに, 面接では「僕の能力で"その能力を持っていない誰か"も僕と同じように幸せに出来るエンジニア, 直近の目標は英語読めるようになりたい」と答えていました.

正直, railsの勉強と就活で全然英語の勉強できてないのが現状です...(；´∀｀)

好きなこと/できないことを言語化すれば, 夢まで見えてくる

12月終わり, はじめての面接で全然自分について話せなくて落選.

自分は劣等だ, できないことばっかりだ...ととても悩んでいました.

今思うと, できないことばっかり考えてるから人に話せるわけがないんですよね.

そんなときは, 自分が好きなことや楽しかった環境を言語化することで, 「自分が大切にしているもの」, 「自分の強み」が見えてくるのかな, と思います.

つまり, それらが自分の「価値観」なんだろうなぁ...

その後に, 自分の価値観の中で, 「できていないこと」を探す.
そして, 自分の「目標」ひいては「夢」を見据えればいいのかな, と思いました.

つぎは, 内定先を決めなきゃな.

ゲームを好きな理由

僕の強み

  • 他人と同じ環境下で自身の力を試し, 試行錯誤で育てる力
  • 勝つために様々な方法で取り組む力(ビデオ撮影, チーム共有)
  • 1人ではなくチームで成果を出すことに喜びを得ること

僕はFPS(主観視点で銃で人と殺し合うゲーム)が大好きです.
小学5年生の時から今までずっと続けています. 他のゲームは殆どやりません.

FPSが好きな理由は, 相手と同装備/同環境下において対等に戦えるからです.

他の人と違うのは, プレイヤーの頭の中,判断力と読みと経験値のみです.
つまりキャラクターの強さをほとんど排除して, プレイヤー個人の能力のみで勝敗が決まるゲームです.

勝つ手段は他人以上の鍛錬を行うこととノウハウを身に付ける以外なく, その鍛錬がとても楽しいです.
自身のプレイ動画を見て反省しながら試行錯誤の中で勝つ方法, 負ける原因を追求していくことが好きです.

それゆえに, 戦いに勝ちそうな時, 死にそうなとき, 負けた時の感情は
他のゲームには代えがたいです. 本当に心臓がバクバクし体から汗が出ます.

一時期, チームに入って練習をしていた時期がありました.
仲間とともに談笑しながら情報を共有し練習する. 時には他チームと試合をして反省会をする. 1人で練習するよりもそんな雰囲気の中で仲間と共に勝ちを追求していくことが好きでした.

以上の理由からFPSが好きです(戦争は完全に反対派です).

iijmioをandroid5で動作させる.

日記

使用端末

HTC desire eye (Android 5.0)

iijmio ウェルカムパックをandroid5の端末で動かすときのヒント

基本設定はIIJmioの公式サイトを見る.
そして, IPv6だとうまくつながらないので, IPv4固定にする.
simの抜き差しを繰り返す.

サポートセンターの回答も上記の内容を

発見したこと

私の端末では, 上記の方法ではうまくいかなかった. 通信方式をauto(2G/3G/4G)から3G固定にすると繋がるようになった.

vimのキーバインド<C-j>がinsertモード移行からmapできない時の解決方法

技術 日記

背景

vimとTmuxをシームレスに移動するためのプラグインを真似したかった.

vimの<C-j>をremapできなかったので, その対策を記す.

やりたかったこと

vim の normalモードで<C-j>に他のキーバインドを当てたい.

できなかったこと

normalモードで<C-j>を入力するとinsertモードに移行する.
:map <C-j>で<Plug>IMAP_JumpForwardが出力される.

解決方法

$HOME/.vim/plugin/imaps.vimの480行目あたりを編集する.
imap, nmap, vmapをコメントアウトする.

" Default maps for IMAP_Jumpfunc {{{
" map only if there is no mapping already. allows for user customization.
" NOTE: Default mappings for jumping to the previous placeholder are not
"       provided. It is assumed that if the user will create such mappings
"       hself if e so desires.
if !hasmapto('<Plug>IMAP_JumpForward', 'i')
  " imap <C-J> <Plug>IMAP_JumpForward コメントアウト
 endif
if !hasmapto('<Plug>IMAP_JumpForward', 'n')
  " nmap <C-J> <Plug>IMAP_JumpForward コメントアウト
endif
if exists('g:Imap_StickyPlaceHolders') && g:Imap_StickyPlaceHolders
 if !hasmapto('<Plug>IMAP_JumpForward', 'v')
  " vmap <C-J> <Plug>IMAP_JumpForward コメントアウト
 endif
else
 if !hasmapto('<Plug>IMAP_DeleteAndJumpForward', 'v')
  " vmap <C-J> <Plug>IMAP_DeleteAndJumpForward コメントアウト
 endif
endif
" }}}

上記でできた.

git revertについて

git revertを理解する上で必要な知識

前回, 前々回でgit reset, git rebaseについて触れた.
ここからはgit resetを理解してることを前提に話を進めていく.
参考ページ Git チュートリアル: 変更を元に戻す | アトラシアン

git revertの概要

git revertは, コミットを打ち消すような動作をする.
コミットの編集履歴を辿り, 前回コミットで変更された部分(差分)のみを"打ち消す"ようなコミットを行う.

git reset と git revertの違い

例として, 前回コミットした内容に間違いが含まれていたため,
前回のコミットを取り消して, 改めてコミットしたい場合を考える.

# コミット A,B,Cがあり, Cに間違いが含まれている. 
# そこで, Cを取り消して, 改めてコミットを行いたい. 

A -> B -> C (間違いを含むコミット) 
          ↑
         HEAD

これを実現する方法は, 2つある.
それがgit resetとgit revertである.

git resetを使った方法

git resetは怖くないgit reset - namu_r21の日記でも触れたように, working tree, index, headを過去コミットの状態に完全に戻すコマンドである.
つまり, そもそも"コミットなんてなかった"という状態にすることができる.

# git resetでCをなかったことにする
 A -> B -> C (間違いを含むコミット) 
           ↑
          HEAD 
$ git reset --hard HEAD~1
 A -> B # Cなんてなかった 
      ↑ 
     HEAD

この状態で改めて変更をコミットすると以下のような状態になる.
ここで, 注意すべきは改めてコミットしたものは新しいコミットとして見なされることである.

# git resetでCをなかったことにした後 
A -> B
     ↑
    HEAD 

# 改めてcommit
$ git commit 
A -> B -> D (Cとは異なるコミットとして扱われる.)
          ↑
         HEAD

git revertを使った方法

対して, git revertは, コミットを打ち消すような動作をする.
前回コミットで変更された部分(差分)のみを"打ち消す".
コミットCはそのまま残し, コミットCによって行われた変更部分を打ち消すコミットを発行する.

# git revertでCで行われた変更を打ち消す
A -> B -> C (間違いを含むコミット)
          ↑
          HEAD 

$ git revert
A -> B -> C -> C' ( Cによって行われた変更を打ち消すコミット) 
               ↑ 
              HEAD

この時, working treeはコミットBと同じ状態になっている. 改めて, コミットを行う場合は以下のような状態になる.

# git revertでCで行われた変更を打ち消した後, 
A -> B -> C -> C' 
               ↑ 
              HEAD 

# 改めてcommit 
$ git commit 
A -> B -> C -> C' -> D 
                     ↑ 
                    HEAD

このようにすることで,
git revertによってログを残しながらコミットCを"なかったこと"にすることができる. ここがgit resetとgit revertの違いである.

なぜgit revertが必要なのか

個人でgitを利用し, ローカルリポジトリだけで開発を行っている場合はこの2つを混同しても特に問題はない. しかし, リモートリポジトリが関係すると話は別になる.

例えば, ローカルでコミットCまで開発しリモート(origin)にpushしてしまった場合を考える.

# 間違いが含むコミットCをoriginにpushしてしまった. 
A -> B -> C (間違いを含むコミット) 
          ↑ 
         HEAD 
       origin/HEAD

git resetを使って, コミットCをなかったことにして
改めてコミットを行うと以下のような状態になる.

# 間違いが含むコミットCを``git reset``によってなかったことにして 
# 改めてコミットを行う. 
A -> B ->  ->  D 
         ↑     ↑ 
  origin/HEAD HEAD 

$ git push origin
CONFLICT!

この状態でgit push originを行うと, コンフリクトが起きる.
origin側からすると,

  • Bと繋がっているはずのCコミットがなくなっている
  • Bと繋がっていないはずのコミットDが送られてくる

という状態になり, エラーを吐く.

これをgit revertを使うことで繋がりを守ったまま
コミットCを処理できるため, エラーを吐かない.

# 間違いが含むコミットCを``git revert``によって"打ち消し"て 
# 改めてコミットを行う. 
A -> B -> C -> C' -> D 
          ↑          ↑ 
     origin/HEAD    HEAD 

$ git push origin
A -> B -> C -> C' -> D 
                     ↑ 
                   HEAD 
                origin/HEAD

チーム開発における git revertの有効性と git resetのヤバさ

チームで開発しているリポジトリのログをgit resetで汚してし,それを共有すると全員のリポジトリでコンフリクトが起きる.

なおかつ, logが残らないので原因追及ができなくて死ぬ.

チーム開発するときは,

  • リモートにpush後のコミットを訂正する際は, git revertを使う( 不用意にgit resetしない)
  • 間違っても, git resetでログをめちゃくちゃにした後にリモートリポジトリに反映しない
  • pushする前に本当にpushしても問題ないかを確認する.

まとめ

  • git revertは，コミットを残しつつコミットの変更を打ち消す.
  • git resetは, コミットそのものを無かったことにする.

git rebaseってなによ？

git rebaseってなに?

前回, 前々回に続いて
今回は, git rebaseについて書く.

git rebaseは コミットログを綺麗にする 機能である.
git rebaseを使えば,

  • 複数のコミットを1つにまとめる
  • コミットのノードを変える

ことができる.

なにも考えずにgit commitしまくって,
後からgit rebaseでログを綺麗にまとめる使い方が主流みたい.

どうやって使うの?

liginc.co.jp

このサイトがとってもわかりやすい.
わかりやすすぎて正直書くことがない...

今後, 使いそうなものをpickupして書こう.

複数コミットをまとめる方法

基本的には, HEADからの距離 か 対象コミットのhash値 を使う.

# -i はinteractiveモード
$ git rebase -i <hash値> or <HEAD~n>

例えば, 2つのコミットを1つにまとめる場合.

$ git log --oneline
...  
fl32k49 commit C
r43ng9c commit B
2Ofncfb commit A

$ git rebase -i HEAD~1
         or 
$ git rebase -i r43ng9c

rebase すると, editorが開く.
ここで, 各コミットの扱いを設定する.

# rebase すると開くファイル  

pick r43ng9c commit B
pick fl32k49 commit C

ちなみに, rebaseファイルで使うコマンドは以下の通り.

  • pick（コミットを採用）
  • reword（コミットを採用するが、コミットメッセージを変更）
  • edit（コミットを採用するが、ファイルを修正する）
  • squash（一個前のコミットと合体させる）
  • fixup（コミットメッセージを変更しない点以外、squashと同じ）
  • exec（shellでコマンドを実行する）

ここで, コミットBにコミットCを結合する場合を考える.

pick   r43ng9c commit B
squash fl32k49 commit C   # squashは s だけでもいい

このファイルを上書き保存すると, コメント編集用のファイルが開く. コメントを書き換えて保存するとrebase完了.

コンフリクト発生!!!

コミット同士を無理やり結合しているので, 衝突する場合がある.
その時, rebaseは一時中断されるのだが, その時に使うコマンドを記す.

  • git rebase --continue（衝突などを解決した後に実行して、rebaseを続行する）
  • git rebase --skip（エラーを無視する）
  • git rebase --abort（rebaseをやめる）

注意すべきこと

rebaseはコミットを書き換えるわけではなく, 新しくコミット を行う

このため, リモートリポジトリのコミットを
git rebaseで書き換えてしまうと大量のconflictを引き起こす.
だから, リモートリポジトリに対しgit rebaseによる編集は控えた方が良い.

リモートリポジトリが関係する場合は, git revertでノードの編集を行うことが慣習になってる.

簡単ながら, git rebaseについてまとめた.