午後から始めるプログラミング

人類、いや私が、幾度となく挑戦してきた、「bashをvim modeで使う」こと。 vimよりもbashは使ってきた時間が長いだけに、ずっと慣れなくて。でも使ってる機能が結局ctrl-eとctrl-aくらいで、他はカーソル移動を頑張ってたところが多いのはわかっていた。 emacs式の移動を覚えようとしたこともあるものの、それを覚えるよりはvimモードで使ってしまうのが速いという結論に至った。altキーとかいちいち覚えてられん。それよりescを押してしまったほうが速い。 結局、決め手は、というより自分の中で決めていて、普通のこういうVimじゃない場面のエディタでVim式のカーソル移動を極普通に繰り出し予想を裏切る動き方をして手が止まったらVim modeにしようと考えていた。 それが、最近はブラウザでこうやって書いていても自然とwやAを押しそうに成るので、これはそろそろかと思って、再び挑戦。 今度はいつまで続くかな。

実はいまのいままで、ずっとUnite.vimを使い続けてきていました。 Shougoさんのunite.vimは確かに素晴らしかったです。しかしながら、私には到底使い切れるものでもなく、もったいないとおもいつつ、ファイラーとmruのみを使う日々が続いておりました。 御存知の通り、随分前にご本人はすでにuniteからdeniteへと移行をしています。 知らなかったわけではないんですが、動いてるし速度にも問題を感じることがなかったので放置していました。 しかし今回、現状に合わせて、この部分を考え直すことにしました。要するにVimのファイラをどうしよう問題です。 で、いろいろ見た限り、わたしには、 https://github.com/cocopon/vaffle.vim これが最も適しているようでした。 ブログ記事はこちらです。 http://cocopon.me/blog/?p=6084 かなり気に入っています。動作はなかなかに速いですし、hjklで移動できる感覚も、なれると良いものですね。 あとはmruをどうしようかなーというところのみとなりました。

https://github.com/goldfire/howler.js 最初はこれ良いかなーと思ったんですが、ちょっと思ってたのと違いまして。 やっぱりこれもriot.jsで作るしか無いかなぁ。

いい感じのライブラリ、あります。 現在作成中のPadio(仮名)というサービスではこれを使っています(が、しかしもしかしたら変えるかも。現状はすごい満足)。 https://github.com/eduncan911/podcast https://godoc.org/github.com/eduncan911/podcast

これからの時代において、Creativeなことでまさに、と思った記事 https://medium.com/web%E7%B3%BB%E3%83%95%E3%83%AA%E3%83%BC%E3%83%A9%E3%83%B3%E3%82%B5%E3%83%BC%E3%81%AE%E9%95%B7%E3%82%81%E3%81%AE%E5%91%9F%E3%81%8D/%E3%83%9A%E3%83%A9%E3%82%A4%E3%83%81%E3%82%84jimdo%E3%82%92%E5%90%A6%E5%AE%9A%E3%81%97%E3%81%A6%E3%81%84%E3%82%8Bweb%E3%82%AF%E3%83%AA%E3%82%A8%E3%82%A4%E3%82%BF%E3%83%BC%E3%81%8C-%E7%97%9B%E6%81%A8%E3%81%AE%E6%A5%B5%E3%81%BF-%E3%81%99%E3%81%8E%E3%81%A6%E7%97%9B%E3%80%85%E3%81%97%E3%81%84-82886075dd78 これについてのResponse(自分の考え)は時間が取れたらMediumで書きます。

MicrosoftのDCについてのASCIIの記事が面白かった http://ascii.jp/elem/000/001/474/1474081/ Mastodonで流れてきたので読みました。Microsoftの厳しいDC(データセンター)の立地要件や、中を案内するときの事が書いてあって面白かったです。 何より面白いのは、知らなければ答えようがないという考え方ですね〜。 私ですと、あらゆるものを共有しまくって、社内でいかに透明化してデータを共有するかという方が効率化できるという考えの人間なので、こういう逆転の発想、また大きい企業で、それなりの責任を求められる企業の宿命(?)的なものを垣間見れて面白かったです。色にまでこだわっているとは。 それにしても、そこまでしても このような ことが起きてしまうというのは、避けがたいのか、それとも…頑張って欲しいです。ついでに言うと私はGoogle Cloudのほうに頑張って欲しいです。 (ここまで書いておいてなんですが、Azureは触ったこともありませんし、触るつもりもじつはありません…。)

NanoLogを試してみたい https://github.com/PlatformLab/NanoLog NanoLogが説明を読む限り、いい感じな気がしました。 (私はGo大好きですが、C++で書かれたソフトウェアにももちろん興味はあります。ただし自分では書きません) ちょっと試してみようとは思っています。

Google Sampleに早速公開されたGoogle Assistant SDKがpython環境があれば簡単に動かせるものがあったので、動かしました。 https://github.com/googlesamples/assistant-sdk-python 参考のリンクはこれだけです。というか、これだけ読んで、この通りにやれば動かせます。めっちゃ簡単にできる割に結構感動は大きい(自分のterminalでマイクから入力を受け取ってスピーカーで返してるところとか、実際には本体はlocalで動いてるわけじゃないんだけど、Helloっていったら名前で返してくれるとか、スマホではもうおなじみだけども、本当にこういう時代が来たんだなぁと)ので、ぜひおすすめ。手軽な満足感が得られます。 おまけ: 自分の投稿

ちょっとずつ、今まで集めてきたGoのやっていて知ったことなどをここに書いていこうと思っています。 と、いいつつ… ちょっと細かい解説記事を書く時間がないので、コードだけ貼っておきます。それだけで理解できると思います。少しいじってみれば理解できます。 https://play.golang.org/p/uLnxjX5FtT

Goはdaemonが弱かった https://de-liker-go.blogspot.jp/2015/11/gogowebapp.html この記事で書いたとおり、私はGoのdaemonについて考えてきました。 解決法 1年ほど前から、Goのdaemonはdockerで実現しています。 (御存知の通り、dockerはGo製ですが、daemonを実行するすべを結構ちゃんと持っているみたいで。serviceなどに頼ればよかったんですが、そこを手で書くのも、パッケージ使うのもなぁと思っていたので、dockerいいなと。) imageはalpineを使っています。これに必要なlibc類をいれて、cgoをnoにして、使っています。今のところこれで問題ないので運用していますが、何か問題が出たらまたここにかくかもしれません。