最近考えてること
先日子供が生まれました。めでたい。
というわけで、これからますます、時間の使い方を考えないといけない。
プログラマ35歳定年説みたいなのが言われる理由がなんとなくわかる。まだ35じゃないけど。30過ぎるとみんなライフステージとか仕事とかいろいろ周りの環境が変わっていくんだ。でもマネージメントなんてちっともやりたかないし、自分で手を動かしてるのが楽しいし、生存戦略みたいなのは常に考え続けてる。ネットを見渡してると自分はたぶん一流エンジニアにはなれそうにもないけど、好きなことをやって面白おかしく生きていくために、自分の居場所は自分で作っていかないといけない。家族もいるので今のところ海外で働くつもりはないけれども、エンジニアとしての格というかステージみたいなものを上げるために、英語は避けて通れないという思いは日に日に感じる。
というわけで、最近は空いてる時間の大半は英語の勉強をしてる。読むのはなんとなく意味がわかるけど、聞くのと書くのが絶望的なので、当面はそこに時間を割いてる。自分の場合は話す必要性は今のところあんまりないので、話すのは一旦置いておく。
聞くのはだいたい移動中とか作業しながらとかに英語でしゃべってるIT系のポッドキャストを聞いていて、寝る前にyoutubeで海外のカンファレンスの動画見たりとか、英語学習系のを見てみたりとかで、特にノルマは決めず、気分次第でとにかく耳を慣らす作戦。
書くのはStackOverflowに回答してみたり、洋書を気ままに写経してみたり。StackOverflowで英作文するとよくタイポするんだけど、最近その理由がなんとなく分かってきた。単に小中学校のときに漢字を書くの間違ったのと同じで、圧倒的に書く量が足りてないんだと思う。なので写経は意外と意味あるんじゃないかという気が個人的にしている。量は質に転化する。そのうち。コツコツ積み上げるしかない。
あともうひとつ考えてることは、仕事でGoのコードを書く機会を自発的に作っていくこと。インフラエンジニアという職種自体はそんなにすぐにはなくならんとは思うのだけど、その役割はどんどん変わっていくと思う。既存のソフトウェアの設定を組み合わせてシステムを作るという従来的なインフラエンジニアの重要度は下がっていき、Infra as Code のDSLが書けるだけのエンジニアの知識はすぐに時代遅れになり、クラウドネイティブなピタゴラスイッチを作ってみてもベンダーのふんどしで相撲を取ってるだけで、エンジニアリングとしての価値は低い。結局のところピタゴラなグルーコードのいらないインテリジェントで自律的なインフラを作るために、ミドルウェアレイヤのコードが書けるソフトウェアエンジニアみたいなのが希少価値が高くて、あるものを組み合わせるのではなくて、特定の問題領域に特化したソフトウェアを新しく生み出せる力がインフラレイヤでも相対的に重要度が増してくると思う。ミドルウェアの領域ではまだまだC/C++が現役だけど、最近Goの勢力が拡大してきているので、Go力を高めていきたい気持ち。でも、子供も生まれたし、趣味でコードを書く時間も減るので、仕事で日常的にGoのコードを書ける環境を作るために、仕事で新しく作るちょっとしたツールとかはGoで書いてる。で、汎用化してOSSとして切り出したりしてみたり。やっぱりなんだかんだ言って、仕事と趣味だと仕事の時間の方が圧倒的に長いわけで、趣味だけだと限界がある。なので如何に仕事でそういう機会を作っていくか、そのために普段からどういう仕込みをしておくかが大事。当面の課題は、次に回ってきそうな仕事を予測して、それを趣味的なアプローチで解決できるだけの事前の仕込みをいかにしておくかという戦略なのかな。
最近だとソフトウェアエンジニアリングに重点を置いたSREみたいなかっこいい呼び方があるけど、信頼性を第1目標に掲げる仕事って、かっこいいこと言っても障害コール対応は切り離せないし、そんな仕事があと30年もできるかというとちょっと自信がない。体力でカバーみたいなのって、システムの重要性が増すに連れて期待値が上がるし、非人道的で家庭を持ってるとさらにつらいと思うんよね。そーゆー自己犠牲で成り立つような場所を主戦場にせずに、もうちょっと抽象的なレイヤで仕事ができるようになりたいなと思うのだけど、雑な文章で特にポエムなのでまとまらないけど、そんなことを最近モヤモヤと考えている。
vimからneovimへの移行
vimからneovimへの移行をしてみた。作業メモ。
インストール
$ brew install neovim/neovim/neovim
.zshrc に以下を追加
export XDG_CONFIG_HOME=$HOME/.config
既存のvimの設定からシムリンクを貼る
$ ln -snfv ${HOME}/.vim ${HOME}/.config/nvim
/Users/m-morita/.config/nvim -> /Users/m-morita/.vim
$ ln -snfv ${HOME}/.vimrc ${HOME}/.config/nvim/init.vim
/Users/m-morita/.config/nvim/init.vim -> /Users/m-morita/.vimrc起動してみる。なんかエラー出た。
$ nvim /Users/m-morita/.vim/init.vim の処理中にエラーが検出されました: 行 317: E518: 未知のオプションです: ttymouse=sgr You need vim compiled with Python 2.6, 2.7 or 3.2 and later support for Powerline to work. Please consult the documentation for more details. 続けるにはENTERを押すかコマンドを入力してください
どうやらneovimではデフォルトでマウスをサポートしてるのでttymouseオプションなくしたっぽい
https://neovim.io/doc/user/nvim.html
.vimrc を以下のように修正
if !has('nvim')
" neovimではデフォルトでマウスサポートしているので不要
set ttymouse=sgr
endifあとPythonサポートがないと言ってる。
もともとPowerlineとか入れてた手元のPythonは2系だったんだけど、あとでneocompleteをdeopleteについでに変えようと思ってたのでPython3系を入れておく。
$ brew install python3 $ python3 --version Python 3.6.1 $ pip3 --version pip 9.0.1 from /usr/local/lib/python3.6/site-packages (python 3.6)
で、pip3でneovimを入れる
$ pip3 install neovim
$ nvim
Traceback (most recent call last):
File "<string>", line 4, in <module>
ModuleNotFoundError: No module named 'powerline'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<string>", line 9, in <module>
File "/Users/m-morita/.vim/bundle/powerline/powerline/vim.py", line 15, in <module>
from powerline.bindings.vim import vim_get_func, vim_getvar, get_vim_encoding, python_to_vim
File "/Users/m-morita/.vim/bundle/powerline/powerline/bindings/vim/__init__.py", line 44, in <module>
vim_encoding = get_vim_encoding()
File "/Users/m-morita/.vim/bundle/powerline/powerline/bindings/vim/__init__.py", line 25, in get_vim_encoding
return vim.options['encoding'].decode('ascii') or 'ascii'
AttributeError: 'str' object has no attribute 'decode'
An error occurred while importing powerline module.
This could be caused by invalid sys.path setting,
or by an incompatible Python version (powerline requires
Python 2.6, 2.7 or 3.2 and later to work). Please consult
the troubleshooting section in the documentation for
possible solutions.
function provider#python3#Call の処理中にエラーが検出されました:
行 18:
Traceback (most recent call last):
File "<string>", line 53, in <module>
File "<string>", line 40, in powerline_troubleshoot
File "/Users/m-morita/.vim/bundle/powerline/powerline/lint/__init__.py", line 12, in <module>
from powerline.segments.vim import vim_modes
File "/Users/m-morita/.vim/bundle/powerline/powerline/segments/vim/__init__.py", line 16, in <module>
from powerline.bindings.vim import (vim_get_func, getbufvar, vim_getbufoption,
File "/Users/m-morita/.vim/bundle/powerline/powerline/bindings/vim/__init__.py", line 44, in <module>
vim_encoding = get_vim_encoding()
File "/Users/m-morita/.vim/bundle/powerline/powerline/bindings/vim/__init__.py", line 25, in get_vim_encoding
return vim.options['encoding'].decode('ascii') or 'ascii'
AttributeError: 'str' object has no attribute 'decode'
続けるにはENTERを押すかコマンドを入力してくださいなんかpowerlineがエラーになるなぁ。
このエラー自体は単にモジュールが読み込まれていないだけっぽいけど、powerlineのissue眺めてたらそもそも現時点ではpowerlineはneovimに正式には対応してないっぽい(?)
https://github.com/powerline/powerline/issues/1287
上のissueでpowerlineじゃなくてairline使えって言われてる。
https://github.com/vim-airline/vim-airline
とりあえず無効化して先に進もう
" PowerLine
if !has('nvim')
NeoBundle 'alpaca-tc/alpaca_powertabline'
NeoBundle 'Lokaltog/powerline', { 'rtp' : 'powerline/bindings/vim'}
NeoBundle 'Lokaltog/powerline-fontpatcher'
let g:Powerline_symbols = 'fancy'
set laststatus=2
endif稼働確認してみる。
neocompleteが動いてなさそう。これはあとでdeopleteに置き換える予定なのでいいや。
deopleteの導入
.vimrc に以下を追加
if has('nvim')
NeoBundle 'Shougo/deoplete.nvim'
let g:deoplete#enable_at_startup = 1
endifnvimを起動
$ nvim
:NeoBundleRemotePlugins を実行。
:NeoBundleRemotePlugins
nvimを再起動すればOK。
補完は速くなった気がする。快適。
airlineの導入
.vimrc に以下を追記
if has('nvim')
NeoBundle 'vim-airline/vim-airline'
NeoBundle 'vim-airline/vim-airline-themes'
let g:airline#extensions#tabline#enabled = 1
let g:airline_theme = 'distinguished'
let g:airline_powerline_fonts = 1
set laststatus=2
endifテーマはどれにするか悩んだけど、distinguishedにするとNormalモードでバッファに未保存の状態でステータスバーの色が変わるので、わかりやすくてよさげなのでこれにしてみた。
Homebrewにコントリビュートした
Golangで書いた社内ツールをどうやって配布しようかなぁというのは悩ましい。一応Rubyの会社なので、全員がGoのビルド環境ない。できればGitHubのReleaseページにビルド済みのバイナリを添付してダウンロードさせたいところなんだけど、プライベートなリポジトリなのでGitHubの認証とかが必要。で、HomebrewにprivateなGitHubリポジトリからダウンロードする機能が欲しいなぁと思って、年末年始にbrew本体のコード読んでたら、なんか行けそうな気がしたので勢いでがっと実装してプルリクエストを投げてみた。メンテナの人にかまってもらって、レビュー指摘もらって、何回かやりとりした末にめでたくマージされた。
New feature: Allow download from private GitHub repository by minamijoyo · Pull Request #1763 · Homebrew/brew · GitHub
自作ツールを黙々と作るのもいいけど、他の人が作ってるツールにパッチ投げるのもよい。今年はコミュ力を上げていきたいのでOSSな活動は継続的にやっていきたい。
2017年の抱負
2016年は以前よりもコード書く機会が増えたり、OSSにパッチを送ってみたりするようになったりし始めたけど、正直まだまだ全然足りてなくて満足してない。
中長期的に見て英語ができないことが活動の範囲や選択肢を大きく制限していることを日に日に感じているので、やっぱりここらで英語をちゃんとやった方がよいんじゃないかと思ってる。というわけで、今年のテーマは英語である。新しいプログラミング言語を学ぶように、英語の文法をちゃんと勉強し直して、毎日何かを書いてみるようにしよう。
あと、最近ひとりで黙々とやっててもフィードバックがないとやっぱり寂しいし、コミュニティとか横の友達を増やしたいなぁとも思う。これは勉強会に行ってLTで発表したりとかで地道にやっていくしかないかなぁ。
やることを決める場合は、やらないことも決めたほうがよいと思う。
とりあえず最近形骸化してきた毎日コミットルールをやめようと思う。ここ数ヶ月Writing Code Everydayを意識してGitHubの芝もいいかんじに茂ってきて、コードを書くことに対する抵抗感みたいなのはずいぶん下がってきたので、一定の成果はあったと思うけど、毎日何かを書くというプレッシャーは、しょうもないREADMEの更新コミットを積んだりしてごまかしたりしている日もあったりして、あんまり本質的ではない日もあった。形骸化したルールは意味ないので廃止する。毎日じゃなくてももっと価値のあるコードを書こう。
もうひとつやめるのは、このブログの毎日更新。これはtwitterが会社の人に監視されているので言いたいことも言えないそんな世の中じゃポインズンって気分になって、ポエム的なことでも書ける場所がよいなぁと思って、ここ数ヶ月書いてて、これも書くことへの抵抗感を大いに下げたことには意味があったと思うけど、毎日分埋めるのに、書けなかった日はあとで思い出して書いたりしてたけど、あとから思い出せないことも多くて、自分で作ったルールで自分がストレスをかんじるとかあんまり健全でもなかった。というわけで、ここも何かポエムっぽいことを書きたくなったことに書くことにする。技術的なメモは引き続きQiitaに書くけど、数日前にちょっと書いたようにQiitaのContributionがいいねになったことはわりと不満で、しばらく英作文の練習を兼ねてstack overflowで遊んでみようかなぁと思ってる。
あと技術的な分野としては機械学習とかAIとかIoTとかフロントエンドあたりは自分で何か形にできる気があんまりしてないので、距離を置こうかなぁとなんとなくぼんやりと考えている。プログラミング言語的にはしばらくGoが手に馴染むようにしたいかなぁ。
とくにまとまらない文章だけど、推敲せずにポスト。コードも文章もアウトプットの瞬発力みたいなのも大事にしたい。
Qiitaのポエム化へのがっかり感
Qiitaは年内にトータル50記事まで行きたいなぁと勝手に思ってて、あと1つだったので書いた。
privateなGitHub Releaseページのリリース物をcurl+jqでダウンロードするワンライナー - Qiita
QiitaのトータルのContributionも570まできた。ただ、最近Qiitaのストックがいいねになったり、アドベントカレンダーでポエムみたいなのがいっぱいいいねを集めてるのを見ると、Qiitaのいいね数と技術的な価値みたいなのはやっぱり違うし、それをエンジニアの戦闘力みたいに見せるのはなんだか違うよなぁというモヤッと感があって、最近エンジニアとしての戦闘力を上げようという文脈でのContribution数を増やすモチベーションがずいぶん下がってきた。まぁ何も知らない人から見るとQiitaのContributionはわかりやすいんだけど。
自分はどちらかというと、ぐぐってたどり着いた10人のための記事をいっぱい書きたいなぁと思ってたので、ポエム化の激しいQiitaよりも技術力のごまかしの効かないStackOverFlowに回答するとかGitHubのIssueに絡みに行くとか、そういうところに時間をかけて実績を積み上げていくほうがよいのかもしれないなぁとぼんやりと考え始めてる。英語力足んないのを場数を踏んでなんとかしたいという思いもある。
