vim上でディレクトリ構造をサイドバーのように表示してくれる便利なPluginにnerdtreeがあります。
これにgrep機能を追加すると便利なので、色々な方がネット上に載せています。
せっかくなのでgrepコマンドではなく、agを使ってみようと思い調べたところ、以下が見つかりました。
https://github.com/taiansu/nerdtree-ag
これでも良いのですが、オプションを自由に指定できません。
自分としては、もっとシンプルに--rb -s hogeのように打てればいいと思いました。
なので作りました。良かったら使ってみてください。
https://github.com/ko2ic/nerdtree-plugin-ag
まずはChocolateyのインストール。
公式ページに書いてある通りにします。
1
| |
次にパッケージをインストールします。
これは、pacakages.config に記述しておきます。
自分の場合は以下です。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | |
1
| |
次はコマンドプロンプトやCygwinを便利にします。
以前に記述したQiitaの記事の通り設定します。
ChocolateyでCygwin（C:¥に）インストール・設定する
次にlanchyの設定をします。
ホットキーを alt + space にします。
また、launchyフォルダを作り、以下のように検索対象のディレクトリに指定する。
このフォルダに検索対象のショートカットを入れたり、シンボリックリンク( mklink コマンドで)などを入れます。
例えば、Cygwinのショートカットを入れて、Launchyの設定で「実行可能ファイルも含む」にチェックに入れるとLaunchyで起動できます。
普段macを利用しているので、caps lockをCtrlに変えたいです。
以下の内容でchangeCapsLockToCtrl.regという名前で保存しておきます。 これを実行すると変更されます。（レジストリをいじってるので自己責任でお願いします。）
1 2 3 | |
MS系開発は個人的には嫌いですが、仕事でやらざるを得なくなったので仕方なくやっています。
（今の案件では、マイクロサービスなアーキテクチャが一番良いと思っていて、Dropwizardが適切だと思っていました。色々な人の思惑があり、PaasなAzureになりました。残念です。）
なによりもMSのクローズドな文化が嫌いなのです。
調査しても情報発信している人が開発者数の割にとても少ない。
あと、決して使いやすいとは思えないVisual Studio。（慣れの問題？違う気がする）
WorkerRoleとかWebRoleとかテストしずらいし、まともなMockフレームワークは、Fakesぐらいでプレミアム以上じゃないと使えないし(Moqがあるけど、JavaのEasyMockレベルで古い感じがするし)。
と色々悪く言いましたが、C#は素晴らしいと思っています。
関数型な部分も取り入れているし(でも何故かSQLっぽい表現)、rubyやgroovyっぽさもあるし、Javaっぽさもある。
素晴らしい。
そして、ようやくMSも本気でオープンになっていく模様。（開発者増えたらライセンス縛りしないかな？）
Visual StudioでNuGetも使えるバージョンがようやく無料で使えるようになる。これは嬉しい。
（というか、例えばJavaのEclipseとVisual Studioは同レベルのツールでしょ。今更なんだよな）
文化が変わるには時間がかかると思うけど、こうした変革で少しでも文化がよくなり、個々人の開発者がたくさんのオープンソースを作っていくようになれば面白くなるかもしれない。
で、そんなこんなのでVisual Studioが家でも使えるようになったので、Qiitaに投稿しました。
C#で日本語受入テストの自動化ができるSpecFlowを使おう
Cucumber for .NetがSpecFlowです。
C#でも出来るんだね。というのが率直な感想です。便利だと思います。
Visual Studioを無料にしたから、こんな感じで記事を書く人も増えるだろうし、そうなると開発者も増えるだろうし、もっと早くオープンにすれば良かったのにな。 これから期待しています。
Qiitaに投稿しました。
railsで初期データを入れる(seed-fuの使い方)
ruby素人なので、seed-fuよりもいい方法はあるかもしれないです。
自分は使ってみて便利に感じたので投稿してみました。
環境を再構築するときに忘れないようにメモ
VMwareのスナップショットはファイルで保存されます。
TimeMachineはファイルの更新日付を見て、対象ファイルかを判断しています。
なので、例えば仮想環境のwindowsに100GB割り当てていれて、windows上で何かをすると100GBのファイルが更新され、TimeMachine対象ファイルになってしまいます。
ということで、仮想環境で差分バックアップすればいいのです。
VMWareではそれをAutoProtectで実現できます。
以下が自分の設定です。
少し前にQiitaにRuby関連の投稿をしました。
Javaエンジニアがいまさら始めるRuby開発環境
本当に久しぶりにRubyを触りました。いまさらですが、すごい良いですね。
最後に触ったのが2006年頃で「RailsはJavaの10倍の生産性」と謳われていました。
それを知ってからすぐに触ってみましたが、確かにすごいと思ったけど、Javaで十分と思っていました。
僕がJavaを好きだったのは、言語というよりもオープンな文化です。
オープンソースなフレームワークもたくさん出てくるし、知的好奇心を満たすのに十分満足でした。
時代は流れ、githubのおかげでコミッターという概念も薄まり、当時よりも様々な言語で個々人がソーシャルにフレームワーク開発に参加できるようになりました。
Rubyはそういったオープンなソースがたくさんあり、それらを利用すれば確かに生産性は高いだろうなと現在は思います。
また、現在のJavaはいまさらlambdaが入るくらい停滞している気がするので、サーバーサイドの仕事もRuby中心に探していきたいですね。（これからはScalaをやろうとしてたけど、やっぱりRubyを極めてからかな）
Dropwizardはwebアプリとしてではなく、ユーザに配布するツールを作成するときにも役に立ちます。
どういうことかというと、dropwizard-configurationというjarだけを利用しましょうということです。
詳しくは、Dropwizardで気軽にユーザ向けのツールを作成する に記述しています。
自分の場合で恐縮なのですが、ソフトアーキテクチャで意識するのは、プロジェクト間の依存関係を疎結合にすることです。
そうすることで、いつでも他のプロジェクトでも利用できるし、その部分だけをまるっと気軽に交換できるからです。
Dropwizardではまさにそれを高いレベルでやってのけています。
なので、RESTフレームワークであるはずのDropwizardをwebとは関係のないツールで便利に利用できるわけです。
この記事も以前書いた「dropwizard-testingが便利でした」と同じくらい有用なことを書いたつもりなので、ぜひ試してみてください。
サンプルソースはこちらです。
https://github.com/ko2ic/spike-groovy-executable-jar
「VagrantでVirtualBox内でubuntuを動かして、そのubuntu内でdockerコンテナを起動して、その中でubuntuを動かす」
という文章にするとややこしいことをすぐ忘れるので自分用にメモしておく。
（この記事ではVagrant1.6からのDocker Provider・boot2dockerを使わない）
Vagrant Boxから適切なBoxを選択する。
まずは、VirtualBox内で動作するubuntuのBoxを使ってVagrantfileを作成する
1
| |
作成した後に、vagrant起動。
この時にboxをローカルに配置している。
boxの配置される場所は ~/.vagrant.d/boxes 。
1
| |
ちなみにvagrant終了はこれ
1
| |
ちなみに破棄はこれ
1
| |
再起動はこれ
1
| |
VirtualBox内で動作するubuntuにsshで接続する
1 2 | |
VirtualBox内で動作するubuntuにはdockerがinstallされていないので、installする。
この際にインストールするのは docker ではなくて、 docker.io 。
全く違うものなので、間違えるとこんなエラーが出るので注意。
参考記事
Segmentation Fault or Critical Error encountered. Dumping core and aborting.
Spring BootとDropwizardの比較をしてみました。
記事はこちらです。
以下は自分の意見です。
いまのところはDropwizardの方がいいかなぁというのが結論です。
ソースの比較をするとSpring Bootの方が記述量も少なくて優れているように思えます。
しかし、実際はDropwizardでは迷うことがなく実装ができ、Spring Bootでは悩むことが多かったです。
おそらく、
Spring Bootは多機能で色々なことができるためソースも多く、調査が大変 –> ごちゃついてる気がするのだと思います。
ただ、この感覚は単純にDropwizardの得意な分野で比較したのが理由かもしれません。
ここで、話は脱線しますが、久々のSpringについても書いておきます。
Springに関しては元々大好きなフレームワークの一つです。
ソースもきれいでわかりやすく、非常に勉強になりました。
きれいなソースと言えば、Seasarプロジェクト（特に本体とSaStruts,S2JDBC）もそうでした。
反対にStruts,Myfacesなどは汚いと思いました。
(きれいなフレームワークは比較的に長生きしているので、その点Dropwizardもきれいなので長生きするかも）
今の時代では、当たり前に利用されているSpringですが、おそらく日本では業務で最も早く利用したプロジェクトに運良く参加していました。
それからバージョン3まで仕事で利用し、Spring MVC, Spring Web Flow, Spring Batch, Spring Securityなど多くのSpringプロダクトを利用していました。
しかし、5年ぶりに実装してみて「こんなにめんどくさかったっけ？」と感じました。
Springも巨大になりすぎたのかなと思います。
手を動かしてはいないですが、ずーと追ってはいたので昔の知識で止まっていたわけではないつもりです。
あれからGuiceなど軽量なDIができたこともあり、そちらで十分な気もします。
話は戻して、Spring BootとDropwizardについてです。
Spring Bootは機能過多な気もしますが、それもメリットとも言えるので、慣れてくれば、Spring Bootの方が良くなるかもしれません。
ちょっとしたホットデプロイならできるので、それも少しメリットかもしれません。
(が、完全じゃないので微妙）
ただ、現在の感想としては
RESTfulなアプリを早くシンプルに作るのであれば、自分だったらDropwizardを採用します。
ソースもシンプルでわかり易く拡張もしやすいように感じます。
(いまの時代、単体テストという面だけでいうとDIである必要もあまりないと思っています。)
Spring Bootは機能過多になったSpringプロジェクトをうまいこと使い易くしてくれる可能性がありそうなので、今後に期待しています。
もっと洗練されて昔のSpringのようにシンプルで、使い易いものになってほしいです。
Dropwizardで試したいことの一つとして、トランザクション境界を変えるというものがありました。
今回は、それをDDDでやるためにguiceを使ってみました。
今の時代、DIコンテナを使う理由はほとんどトランザクション境界を永続化層に依存させたくないからじゃないのかなと思います。
昔は、単体テストをできるようにすることがDIを使う主な目的でしたが、今はJmockitなどモックフレームワークの充実で、簡単に単体テストができる時代になりました。
ということで、トランザクション境界を変えてみたことをQiitaに記述しました。 http://qiita.com/ko2ic/items/409bfecfd806c2f903e1