クレバーに動こう
地震、津波、原発と大混乱の日本が続いています。
自分の周りも直接的に大きな被害があったわけではないですが、買い占めや計画停電など生活に少しずつ変化が出てきています。
こういった不便はしばらくは仕方ないでしょうね。
会社でもあたふたして空回りしている人を見かけます。
自分の上司もちょっとあたふたしてて頼りない。
しっかりしてよ。
こんなときだから、冷静に優先度を付けて行動しないと。
自分が今週優先したのは、地震初日の移動の混乱、帰宅難民の状況を見て、移動しなくても仕事を継続できる仕組みを組むことでした。
そのために一部予定していた作業を止めたりもしました。
うまくいったと思う。
うちのチームは、家からでもなんとか作業できるはず。
今後、電力不足は続くだろうから、この状況は長期化すると思っていたので、まっさきに作ろうと思った。
不謹慎かもだけど、後輩と一緒に楽しみながらやってます。
これを通じて新しいことを覚えられてるからね。
買い占めなどもどう考えても論理的な行動じゃない。
自分にとって、周囲にとってメリットになるか考えて行動しよう。
心理的に仕方ないんだけど。
動ける人、特に子供がいらっしゃる家庭で共働きじゃない家庭は、苦労しながら暮すよりは一時的に中部、関西に疎開するのもいいでしょう。
ホテル暮しはきついので、親類が居る方ということになると思いますが。
自分がその立場だったら子供学校休ませて、奥さんと関西の実家に疎開させます。
原発、物不足で苦労させながら暮らすよりはよっぽど安心。
とはいえ自分も冷静かというと、余震が結構怖い。
今のところ原発より怖い。
だって即死できるし。
その辺でストレス感じてるけど、音楽聴いたりできるだけ何かに集中して紛らわしてます。
しばらくこんな状態が続くでしょうが、頑張りましょう。
あ、停電やらの混乱で深夜アニメ録画めちゃくちゃなのなんとかして。。。
阪神大震災と今回の大地震を体験して
コンスタントにblogを書く目標を立てておきながら、1ヶ月書けませんでした。
久しぶりのポストがこんな悲しい出来事というのは遺憾ですが。
私は、元々関西の人間で阪神大震災の時期も向こうに居たのですが、こんな短期間に2度も大地震を体験するとは。
今日の地震時は、オフィスに居たのですが、ビルの最上階で少し高かったこともありかなりの揺れでした。
周りの人達は結構冷静だったのですが、自分は結構動転していました。
同じ阪神の震災を体験した方も同じように結構動転していたので、やっぱり体験している人間の方が深刻に捉えていたみたいです。
みんな逃げだすなどのパニックは起きなかったのはよかったです。
二つの大地震を体験して感じたことは、やはりネットの進化です。
今回、地震時うちのオフィスはすぐに停電になったのですが、すぐにスマホ使って Twitter で情報収集できました。
Docomoは苦戦していたみたいですが、Softbank や au は結構いけました。
阪神大震災のときはこんな情報収集はできなかった。
ネットはもちろんあったけど、まだ Twitter のようなサービスと呼べるものはなかったから、せいぜいメール。
情報のほとんどを報道に頼るしかなかった。
なので、神戸の映像が入ってきたときは、とても驚いたものです。
大学に行って友人から各地の状況を聞いてようやく見えてきた。
今回は、揺れてる最中からネットで状況を知ることができたのは、冷静さを保てた要素の一つかもしれません。
近くではない、とか、都心勤務の人も無事そう、とか、深刻度を知ることができたので、ある程度冷静でいられました。
落ちついた後、ワンセグで報道を確認して震源地や震源地の津波の情報を知って恐しくなりましたが。
ネットが確実に緊急時の情報インフラとして、多大な効果を上げていることを実感した一日でした。
内閣官房のページや東電のページなども相当アクセスが来ていると思いますが落ちずにもっているのも、さすがです。
政府は、今回の震災でネットというインフラの価値をもっと理解してほしいです。
今日は、冷え込むみたいです。
家に辿りつけていない方は、今日はあきらめて学校や公共施設に避難して朝を待ちましょう。
津波被害など大きな被害が出ている地方の方々の無事を祈ります。
プライベートなMavenリポジトリを立てる
Mavenは、複数のリポジトリから依存ライブラリをかき集めてBuildすることができますが、もちろん自身が開発した物件をプロジェクト内だけで使うプライベートなMavenリポジトリでホストしてプロジェクトチーム内で共有することができます。
リビジョン管理とこのようなリリースBuildのコントロールによって、テストなどのレポート、解析を効率よく進めることができます。
立てる方法もやってみるとすごく簡単。
1. リポジトリとなるサーバを立てる
まずリポジトリサーバを立てます。
今回は、クライアントからリリース物件の転送を scp を使う方法で作ってみるので、Linuxで立てるのが楽です。
まず、リポジトリのメンテナンスユーザを作ります。
自分は、プロジェクト名のユーザを大体作ります。
# sudo useradd necomimi
次に、scp をするためにリポジトリとなるディレクトリを作成します。
necomimi# mkdir /project/maven
次に、Nexus を上げます。
Nexus は、Mavenリポジトリのプロキシとしての役割りを果たしてくれて、外部のMavenリポジトリをキャッシュしてくれたりするのですごく便利です。
今回のテーマであるプライベートリポジトリを立てるのに必須ではないのだけど、Mavenをがっつり使うのであればマストと言っていいツールです。
Nexus と Hudson は、マスト。
といっても、これは Nexus の war を Tomcat などの JEE サーバに配備するだけなので割愛。
今使ってるプロジェクトでは、Jetty で運用しています。
Nexus を立てて基本的な設定が済んだら、リポジトリの Add で Hosted Repository を追加します。
この辺の画面見てください。
これは、自前のプライベートリポジトリを立てる機能です。
いくつか設定がありますが、ほとんどデフォルトでよくて、IDやNameは適当なものを入れて、Override Local Storage Location のところに上で作ったリポジトリ用のディレクトリを入力します。
上の例だと、/project/maven
これで保存したら終了。
2. クライアントを設定する
リリース作業を行なうクライアントの設定をします。
リリース作業は、各開発者よりはリリースを管理するリリース担当者がやるので、その人の端末の設定になります。
まずは、Mavenの設定にリポジトリサーバの認証情報などを設定します。
いろいろやりかたはあるのですが、今回はssh-keyベースの認証で scp するようにします。
まず、ssh-keyを作ります。
既に作成済なら、それを使えばよいです。
someone# ssh-keygen
これで、~/.ssh に id_dsa (秘密鍵), id_dsa.pub (公開鍵)ができるので、id_dsa.pub の内容を1で作ったリポジトリサーバのリポジトリのメンテナンスユーザのホームの .ssh/authorized_keys に追記します。
上の例だったら necomimi ユーザのファイルです。
なければ作成してください。
これは、パーミッションを600 にして勝手に書き替えられないようにしておいてください。
次は、Mavenの設定にリポジトリサーバの情報を設定します。
以下のように設定ファイルを書きます。
- ~/.m2/settings.xml
<servers> ... <server> <id>necomimi-repository</id> <username>necomimi</username> <!-- リポジトリのメンテナンスユーザ --> <privateKey>/home/someone/.ssh/id_dsa</privateKey> <!-- 秘密鍵 --> <filePermissions>664</filePermissions> <directoryPermissions>775</directoryPermissions> <configuration> <sshExecutable>/usr/bin/ssh</sshExecutable> <!-- sshコマンド --> <scpExecutable>/usr/bin/scp</scpExecutable> <!-- scpコマンド --> <sshArgs></sshArgs> </configuration> </server> </servers>
これでクライアントの設定は完了。
3. プロジェクトのpom.xmlの設定
最後に、リリース対象となるプロジェクトのpom.xmlを設定します。
設定すべきことは、リポジトリサーバの指定と、scp を実行してくれる拡張機能の設定です。
拡張機能には ftp などもあるので、サーバの環境に合わせて変更してください。
ここでは、詳しくは書きません。
- pom.xml
<project> ... <distributionManagement> <repository> <id>necomimi-repository</id> <!-- example.com の /project/maven にリリース --> <url>scpexe://example.com/project/maven</url> </repository> </distributionManagement> <build> <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ssh-external</artifactId> <version>1.0-beta-6</version> </extension> </extensions> </build> .. </project>
これで設定は完了。
リリース作業は、
someone# mvn deploy
だけです。
これで、リポジトリサーバの /project/maven 以下に、Mavenリポジトリにおなじみのディレクトリ構成とリリース物件である jar や チェックサムファイルなどが配備されているはずです。
これを、Nexus の Hosted Repository 経由で参照できるので、プライベートなMavenリポジトリとして利用できます。
Nexus を使わないのであれば、ApacheHTTPなどを立てて、リポジトリディレクトリを公開するだけでもOKです。
この辺、大した時間かからないけど、方法を調べたりしてると意外に面倒でなかなか実行しないことが多いので、まとめてみました。
git のマージツールを設定する
会社で導入したら、周りの人間に使い方理解できないとか、意味不明なことを言われている git ですが、マージツールとかを使いやすいものに替えるだけでも障壁を下げれるのかと思いその辺の設定をまとめておきます。
マージツールのオススメは、マルチプラットフォームで動く Perforce Visual Merge and Diff Tools (p4merge) です。
こいつを git のマージツールとして設定します。
Mac前提でまとめますが、他の環境でも同じなので多分問題ないです。
まず、p4merge をインストール。
Macなので /Application にドロップするだけ。
次に、以下のようなシェルを書きパスが通ったディレクトリに保存して実行権を付けておきます。
Linuxとかなら P4MERGE 変数をインストールした p4merge コマンドに書き替えるだけ。
- p4merge
#!/bin/sh P4MERGE=/Applications/p4merge.app/Contents/MacOS/p4merge ${P4MERGE} $*
- p4diff
#!/bin/sh P4MERGE=/Applications/p4merge.app/Contents/MacOS/p4merge [ $# -eq 7 ] && ${P4MERGE} "$2" "$5"
次に、git のグローバルコンフィグに以下のエントリを足して、git mergetool で使うツールとして p4merge を指定します。
- ~/.gitconfig
[merge]
keepBackup = false;
tool = p4merge
[mergetool "p4merge"]
cmd = p4merge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
keepTemporaries = false
trustExitCode = false
keepBackup = false
[diff]
external = p4diff
これで、git mergetool でグラフィカルにサクサクマージしましょう。
Squidで中間Proxyを立てる
実験環境なんかで、プライベートなネットワーク組むことがよくあるのですが、その際外部ネットワークに HTTP だけは通したいことがよくあります。
OSのパッケージインストールとか、Mavenビルドとかね。
そういうときには Proxy を立てますが、いっつも忘れるのでメモ。
構成的には、プライベートネットワーク内のマシンは、ここで立てるProxyサーバを通して社内ネットワークに接続。
社内ネットワークには、インターネットに出るための社内Proxyサーバが別途立っていて、そこを通らないと Firewall が越えられない前提。
さらに、社内ネットワークのマシン群には、社内Proxyを通さずにHTTPする必要がある。
微妙に、特殊かもしれませんが。
# sudo apt-get install squid
で、/etc/squid/squid.conf を以下のように。
#1
http_access allow CONNECT SSL_ports
#2
cache_peer parent.proxy-server parent 3128 7 no-query
#3
acl local-servers dstdomain my.internal.domain
always_direct allow local-servers
#4
never_direct allow CONNECT
#5
forwarded_for off
#1 で SSLポート(デフォルトで定義がある)への接続を許可。
#2 で 社内Proxy(parent.proxy-server)を親Proxyとして設定。これで、外へのアクセスは、社内Proxyへパス。
#3 で 社内ネットワーク(my.internal.domain) へのアクセスは社内Proxyにパスせず直接接続。
#4 で 社外ネットワークに接続する場合のSSL接続は、社内Proxyへパス(SSLはデフォルトで直接接続しようとする)
#5 で 一応IP隠す。
という感じ。
設定は、順番で動作が変わるのでその辺はまることがある。
