Think Twice

Memorandum

gradleでproxyのNTLM認証を超える

IntelliJ IDEAのSystem proxyでconnection checkをしてOKでも、
gradleでは407のステータスが返される。

Could not GET 'http://repo1.maven.org/maven2/com/android/tools/build/gradle'. Received stats code 407 from server: Proxy Authentication Required


http://www.gradle.org/docs/current/userguide/build_environment.html
http://gradle.monochromeroad.com/docs/userguide/build_environment.html
上記サイトを参考にgradle.propertiesに設定してもうまくいかない。

IDEAのGradle Setting File>Settings>Gradleもダメ。
build.gradleでSystem.out.println(System.getProperty("https.proxyHost"));
とかやると設定できていることは確認できるがどうにもproxy認証を通らない。

いろいろ検索してみると、NTLM認証はどうも曲者らしい。
NTLM認証を超えるにはCNTLMがよいとか。

http://blue-red.ddo.jp/~ao/wiki/wiki.cgi?page=NTLM%C7%A7%BE%DA%A4%CE%A4%BF%A4%E1%A4%CEProxy%A4%F2%CE%A9%A4%C6%A4%EB
を参考にcntlmを動かしてみた。

やっとproxyを超えることができた。やれやれ。
これで思う存分開発できるヨ。

IDEAでgradleを動かす

前回、オレオレ証明書の対策をして、gradleを動かしたら…
これまでとは違って、何かが始まる予感。
やっと、gradleが動いた!っとおもったら、
今度は"Unable to start the daemon process."というエラー。
これは
f:id:mix-juice001:20141203222411p:plain

ここのGlobal Gradle settings の
service derectory pathにある、gradle.propertiesに下記の1行を追記すればOK。

org.gradle.jvmargs= -Xmx512m

続く

ideaのproxy設定をしようとしたら、man-in-the-middle attackを受けていたでござる。

                        やつを追う前に言っておくッ!
                    おれは今やつのスタンドをほんのちょっぴりだが体験した
                  い…いや…体験したというよりはまったく理解を超えていたのだが……
         ,. -‐'''''""¨¨¨ヽ
         (.___,,,... -ァァフ|          あ…ありのまま 今 起こった事を話すぜ!
          |i i|    }! }} //|
         |l、{   j} /,,ィ//|       『おれは奴の前で階段を登っていたと
        i|:!ヾ、_ノ/ u {:}//ヘ        思ったらいつのまにか降りていた』
        |リ u' }  ,ノ _,!V,ハ |
       /´fト、_{ル{,ィ'eラ , タ人        な… 何を言ってるのか わからねーと思うが
     /'   ヾ|宀| {´,)⌒`/ |<ヽトiゝ        おれも何をされたのかわからなかった…
    ,゙  / )ヽ iLレ  u' | | ヾlトハ〉
     |/_/  ハ !ニ⊇ '/:}  V:::::ヽ        頭がどうにかなりそうだった…
    // 二二二7'T'' /u' __ /:::::::/`ヽ
   /'´r -―一ァ‐゙T´ '"´ /::::/-‐  \    催眠術だとか超スピードだとか
   / //   广¨´  /'   /:::::/´ ̄`ヽ ⌒ヽ    そんなチャチなもんじゃあ 断じてねえ
  ノ ' /  ノ:::::`ー-、___/::::://       ヽ  }
_/`丶 /:::::::::::::::::::::::::: ̄`ー-{:::...       イ  もっと恐ろしいものの片鱗を味わったぜ…

IntelliJ IDEAで社内のproxy経由でgradle使用するとして設定したときに気づいた。

社内はproxyを通してインターネット接続しているので、
まずはproxyの設定
File>Settings でSettings画面を表示。
Appearance & Behavior > System Settings > HTTP proxy

Manual Proxy configurationをこんな感じで設定。(proxy.pacで設定したかったけど、うまくいかず…)
f:id:mix-juice001:20141203222422p:plain

Check connection でhttp://www.google.comへの接続を確認してOK。

gradleをrefreshしようとすると、こんなエラーが発生。

Problem with connection: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

先ほどのproxy setteingの画面でCheck connectionをhttpsで試してみると、同じエラーが。
f:id:mix-juice001:20141203222418p:plain

ググってみるとjavaオレオレ証明書では接続できないとのこと。
オレオレ証明書なんか使ってないのになぁ~と思いながらも確認してみると…

f:id:mix-juice001:20141203222426p:plain

なんと、httpsの通信を横取りするためのオレオレ証明書が知らぬ間にパソコンに入っている!!
うちの会社の環境はナチュラルにman-in-the-middle状態じゃないか!!!

仮にもシステム会社なのに、なんでこんなことになっているんだ。
ホントしょうもないことをする。

気を取り直して、オレオレ証明書でも接続できるようにする。

ここ(http://code.google.com/p/java-use-examples/source/browse/trunk/src/com/aw/ad/util/InstallCert.java
にあるInstallCert.javaコンパイルして実行すれば、OKのはずなのだけれど、
接続がタイムアウトしてできない。

java InstallCert xxx.xxx.xxx.xxx:8080 changeit


気を取り直して、
keytoolでcacertに設定を追加できるようなので、やってみる。
certmgr.mscを起動して、先ほどのオレオレ証明書をエクスポートする。
f:id:mix-juice001:20141203222354p:plain

keytoolにPathを通して、

C:\>keytool -importcert -v -trust
cacerts -file \Users\xxxxxxxx\Desktop\oreore.cer -keystore "\Program Files\JetBrains\IntelliJ IDEA Community Edition 14.0.1\jre\jre\lib\security\cacerts" -alias aliasName

aliasは指定しないとmykeyになる。
私の環境ではC:\の下のファイルを変更するには管理者の権限が必要で、
そのままではkeytoolが失敗するので、
デスクトップにcacertをコピーしてkeytoolを実行後、目的の場所にコピペした。
キーストアのデフォルトのパスワードはchangeit

所有者: CN=ABL-CA, DC=ABL, DC=com
発行者: CN=ABL-CA, DC=ABL, DC=com
シリアル番号: 2bd7ef9c2afac79b470d0acc131eefc4
有効期間の開始日: Fri Mar 08 11:08:25 JST 2013終了日: Wed Mar 08 11:18:23 JST 20
23
証明書のフィンガプリント:
MD5: 63:E5:B1:3C:65:08:7A:2E:92:8F:27:D0:57:68:55:9A
SHA1: 5E:B1:AD:3F:E4:E2:1A:AD:11:EC:B5:E7:DB:C6:35:F7:60:18:15:9A
SHA256: 0C:DF:0E:00:7F:EF:3D:35:D5:06:C7:9D:50:2E:46:97:70:3F:7D:90:F9:
51:F0:04:C3:27:CF:80:E2:99:D8:10
署名アルゴリズム名: SHA256withRSA
バージョン: 3
拡張:
#1: ObjectId: 1.3.6.1.4.1.311.20.2 Criticality=false
0000: 1E 04 00 43 00 41 ...C.A

#2: ObjectId: 1.3.6.1.4.1.311.21.1 Criticality=false
0000: 02 01 00 ...

#3: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:true
PathLen:2147483647
]
#4: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
DigitalSignature
Key_CertSign
Crl_Sign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 8B EF DE 57 F9 C0 80 B7 45 87 53 13 5D A8 D7 1C ...W....E.S.]...
0010: 99 A0 3F 32 ..?2
]
]
この証明書を信頼しますか。 [いいえ]: y
証明書がキーストアに追加されました
[\Users\takumasetoguchi\Desktop\cacertsを格納中]

これで、javaオレオレ証明書を認識できるようになった!

でもまだ続く。

予想どおりに不合理〜Predictably Irrational

予想どおりに不合理 行動経済学が明かす「あなたがそれを選ぶわけ」 増補版

予想どおりに不合理 行動経済学が明かす「あなたがそれを選ぶわけ」 増補版


この本、おもしろい。
人がなぜ、合理的な行動をしないか興味深いいくつもの実験で明らかにしていく。

相対性の真理

人は相対的にしか判断・評価できない。
同じくらいの魅力のAとBを用意し、その2つだけで評価するとほぼ半分ずつの選ばれる。
しかし、ここにおとりの選択肢A’(Aよりも少しだけ劣る)を用意すると、
Aを選択する人が圧倒的に増える。
人は絶対評価はできず、相対的な評価で物事を判断・選択している。

自分よりもすこしだけ劣る人と一緒にいるようにすると、
自分の魅力は実際以上に評価される。

需要と供給の誤謬

需要と供給はほっておいても、需要曲線と供給曲線が交わるところで落ち着くとされているが、
人はモノの価値を本当には理解していない。(できない。)
一番最初に感じた価格に刷り込まれ(アンカリングされ)その価格に少なくない影響を受ける。

ゼロコストのコスト

人は無料の魅力に抗うことはできず、非合理的な選択をしてしまう。
(”無料”に惑わされ、損得計算ができなくなる。)
無料のモノにひかれることで、本当に自分にとって利益のあるモノ、機会を失ってしまう。
逆の立場から考えると、何かを(一部を)無料にすることで、人々を引きつけることができる。

社会規範のコスト

社会規範でなりたっているところに市場規範(お金)を持ち込むと、社会規範は消滅してしまう。
人に何か頼むときはお金の報酬ではなく、(たとえ同じ金額であっても、相手の好みでなくても)プレゼントを買って渡した方がよい。

性的興奮の影響

性的に盛り上がると、冷静な判断はできなくなる。(あるあるすぎる。)

先延ばしの問題と自制心

人は何でも先延ばししがちだが、自分で決意表明することにより、先延ばしの問題を解決できる。
もしくは、なりたい(理想とする)自分に近づけることができる。

高価な所有意

自分の所有しているものは実際以上に、高く評価する。
ネットオークションで入札すると、自分のものになったような気がしてくる。
そのときに、他人が自分の入札額を上回ると、当初の予算を超えていても無理して落札してしまう。

扉をあけておく

選択肢が複数あると、どちらかを選んだ方が(仮に選択としては、よくない選択でも)本来の目的を達するのに、どちらも選べなくなってしまう。

予測の効果

人は予測(予想)したことに沿うように感じる。
駅で超一流のバイオリニストがパフォーマンスしていても、気づかない。
また、超一流のホールで、素人が演奏してもそれに気づくことはできない。
雰囲気がとっても大事で、内容はその次である。

価格の力

高価な薬と安価な薬では成分がおなじでも高価な薬のほうがよく効く。
プラセボ効果はあなどれない。

不信の輪

共有地の悲劇”のように、全員が全員の利益を考えて行動すると、全体の利益が最大になるが、
自分一人の利益を最大にするように行動すると、結局は自分の利益も全体の利益も最小になってしまう。
よくないイメージがついていると、実際にはそうでなくとも、よくないイメージに引きずられ、実際の価値どおりに評価できない。

私たちの品性について

私たちは不正直になりやすいが、道徳的なことを心に思うだけで、自分に正直になることができる。

こう書いてしまうとそうだよねという感じになってしまうけれど、
著者が行った実験が本当にユニークでおもしろい。

TEDでも話している。

ダン・アリエリー:我々は本当に自分で決めているのか?(2008) - YouTube

LEAN IN

LEAN IN を読んだ。

とても読みやすく、内容もとても興味深かった。
シェリル サンドバーグはすごいな。文才もあるのか。
と思ってたら、あとがきで専門のライターがいることが書かれていた。

とはいえ、内容は本当に興味深く、おもしろかった。

仕事と育児の両立

「仕事と育児の両立すごいですね」と女性だけに(ほめてるつもりで)言うのは差別を無意識のうちにしている。
上記の言葉を男性には言わず、女性だけに言うのはおかしい。
仕事も育児も性別に関係なく、なんとかやっていかなければならないことだ。
この両立の話のくだりは自分が無意識に差別しているということに気づかされ、本当にショックだった。

仕事の基準

「仕事を決めるときの基準は一つしかない、それは成長、それも急成長だ」
サンドバーグgoogleに行くかどうか悩んでいたときに、エリックシュミットが彼女にしたアドバイスである。
自分のことを考えると全然あてはまらない。うちの会社は成長しているだろうか?衰退?停滞している気もする。

新しいポストへのチャレンジ

空きポストができたときに女性は必要条件や資格を100%満たしていないと応募しないが、
男性は60%程度で応募するそうだ。(アメリカの話)
私は女性ではないが、サンドバーグのアドバイスに従って、
「私はあれをやってみたい。きっとやりながら学んでいける」と考えるようにしよう。

円滑なコミュニケーション

自分の見方があれば、相手の見方もある。
唯一絶対の真実など存在しない。
これらを理解し、自分は自分の視点からだけものごとを見ているのだということに気づけば、
自分の見方を相手に強要することはなくなる。
そして、「私はこう思う」という形で建設的な意見表明ができる。

相手の感情を慮る

「あなたは私の提案を全然真剣に考えていませんね。」
「ここ4通のメールに返事がないので、当惑しています。私の提案はあなたにとって重要ではなかったのでしょうか?」
どちらがよい言い方か。
このあたりは”I Message”に通じるものがある。

フィードバック

耳がいたくなるかもしれないが、
「どうすればもっとよくできたでしょうか?」
「私が見落としていることはありませんか?」
とフィードバックを求めることが重要。

すべてをやろうとするな

すべてをやろうとすると燃え尽きてしまう。
自分で仕事をコントロールすることが大切だ。
長く仕事で成功をおさめる秘訣は、自分にだされた要求をすべてこなそうとしないこと。
仕事の上限を決め、決めたら守り、仕事とプライベートの両方の余地をつくる。


最後にFacebookの壁に貼ってあるらしい言葉を引用する。

What would you do if you weren't afraid?
(怖がらなければ何ができる?)

Fortune favors the brave just now.
(運は勇気あるものに味方する)

とりあえず始めよう、大胆に

チーム開発力強化セミナー 〜 オブジェクト指向設計の勘所 〜

チーム開発力強化セミナー 〜 オブジェクト指向設計の勘所 〜 - ギルドワークス | Doorkeeper
に参加してきました

今回のテーマも引き続きリファクタリング
マーティンファウラーのリファクタリング
最初のレンタルビデオのサンプルコードをリファクタリングします。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

  • 動く、動かない
  • 美しい、美しくない
  • オブジェクト思考らしい、らしくない

というのは個人の主観が大きく入るが、
変更コストを下げる」というのをチームとして共通の価値観、方向性とするために
どうすればよいかを考るのが大切。

印象に残ったことをメモ。

カプセル化

カプセル化は下記のことを考える。

  • ロジックの置き場所を考える
  • コードの固まり(意味のある固まり。空白行で分割されがち。)を容れものにいれる。(カプセル化
  • 意味ある単位を容れもの(メソッド、クラス、パッケージ)にいれる。

データの場所とロジックの場所を調整しつづけることが大事。

長い引数リストは改善する。

メソッドの引数が2つ以上、ある場合、引数が多すぎる。(引数は1つまで。)
あまりよい例が思いつかないけど、たとえば、

class Hoge
    public void hugehuge(double latitude, double longitude) {    
	//……
        Address address = Geocoder.reverse(latitude, longitude);
        //……
    }
}

ではなく、

class Hoge
    public void hugehuge(Position position) {    
	//……
        Address address = Geocoder.reverse(position.latitude, position.longitude);
        //……
    }
}

のほうがよく、さらに

class Hoge {
    private Position position = new Position(latitude, logitude);
    public void hugehuge() {    
	//……
        Address address = return position.reverseGeocode()
        //……
    }
}
class Position {
    private double latitude;
    private double longitude;
    public Address reverseGeocode() {
        return Geocoder.reverse(position.latitude, position.longitude);
    }
}

のほうがよい

業務の考え方を愚直にコードで表現する

今回の例では++

point++;

プログラマーには何のことかわかるが、ビジネスサイドには理解されない。

point += 1;

とすると、ビジネスサイドにも理解できるし、+=2、+=1.5にも変更しやすい。

design by contract と防御的プログラミング

ロジカル・シンキング

ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)

ロジカル・シンキング―論理的な思考と構成のスキル (Best solution)

頭ではわかっていてもなかなか自然には出てこない。
練習問題もたくさんあって、論理的思考の練習になる。

コミュニケーション

  1. 相手に答えるべき「課題(テーマ)」の確認

課題(テーマ)は注意していないとずれてしまうことがよくある。
とくにたくさんの資料を調査・検討したときほど、陥りがちで注意する必要がある

  1. 相手のどのような「反応」を期待するのか確認
  • 相手に「理解」してもらう
  • 相手に「意見や助言、判断などをフィードバック」してもらう
  • 相手に「行動」してもらう
  1. 何を言えば「答え」になるか(答えの要素)
  • 結論

課題に対する、書き手(伝え手)の答えの核をなすもの。
何かのアクションを提示する場合と、評価や判断を表すものの2つがある。

  • 根拠

その結論にどうして至ったのかという理由。
結論の必然性について相手を納得させられるもの。
事実と判断の2つ

  • 方法

結論がアクションの場合、相手がそのアクションをとれるよう、
具体的なやり方を提示するもの。

論理的に思考を整理する技術

MECE(Mutually Exclusive Collectivelly Exaustive)

相互に排他的で、集合として余すところのない

MECEフレームワーク
  • 3C or 4C

事業、あるいはその企業や業界の現状を検討する場合のフレームワーク
顧客・市場(Customer),競合(Competitor),自社(Company)+チャネル(Channel)

  • 4P

マーケティングについて考える際のフレームワーク
製品(Product),価格(Price),チャネル(Place),訴求方法(Promotion)

MECEの切り口の探し方

単語に分けてみてMECEの切り口を探す。
たとえば「自販機で買える飲料」という課題ならば、「自販機」、「買う」、「飲料」で切り口を考える。
"自販機"なら…メーカー別/置き場所
"買う"なら…価格帯/買う目的
"飲料"なら…容量/パッケージ種類/温度/成分

So What?/Why So?

観察の〜、洞察の〜の2種類がある。

So What?

手持ちのネタ全体、もしくはフルーピングされたものの中から、課題に照らした時に言えることの要素を抽出する

Why So?

So What?した要素の妥当性が、手持ちのネタ全体、もしくはフルーピングされた要素によって証明されることを検証する

論理的に構成する技術

論理とは結論と根拠、もしくは結論とその方法という複数の要素が、結論を頂点に縦方向にはSo What?/Why So?の関係で階層をなし、横方向にはMECEに関係づけられたもの

並列型

根拠や方法を列挙する。

  • 課題やテーマに対して、十分な理解度や興味を期待できない相手に、自分の論旨の全体像を簡潔に示す
  • 決定事項の連絡や確認など、結論に関して、相手とは議論の余地がない内容を、全体像を簡潔にして伝えたい
  • 自分の思考や検討の広がりに、重複や漏れ、ずれがないことを強調して相手を説得したい

ときなどに使える。
f:id:mix-juice001:20140902154712p:plain

解説型

結論の根拠が

  • 課題に対する結論を導きだすために、相手と共有しておくべき「事実
  • 「事実」から、結論を導き出すための伝え手としての「判断基準
  • 「事実」を「判断基準」で判断した結果、どのように評価されるのかという「判断内容

f:id:mix-juice001:20140902154700p:plain