コグノスケ

USB 3.0の帯域を活用

週刊アスキー - Surface 3や薄型ノートPCをわずか1万円強で超強化する棒型ドック、その名も“ピッコロ”を読んで。

USB 2.0の帯域だとFull HDの外部ディスプレイだけで一杯一杯でしたが、USB 3.0の帯域ならWQXGAの外部ディスプレイ＋外付けストレージx 2でも余裕なんですねー。

メモ: 技術系の話はFacebookから転記しておくことにした。

IntelliJ IDEA 14の自動インデント

目次: Java

IntelliJ IDEA 14のエディタにはコードを選択してCtrl+Alt+Iを押すと、自動的にインデントを調整してくれる機能があります。この機能、Javaのコードスタイルに合わせてインデントを調整するので、基本的には文句のない結果になります。

しかしながら、個人的に1点だけ気に入らない点があります。何かと言うとswitch文の内部にあるcaseに余計なインデントが付くことです。例を挙げると、デフォルトでは下記のようにインデントしてくれます。

switch (a) {
    case 0:
        doCase0();
        break;
    default:
        doDefault();
}

本当は下記のように、switchとcaseの位置が揃ってほしいのです。

switch (a) {
case 0:
    doCase0();
    break;
default:
    doDefault();
}

この程度、設定（※）で何とかなるだろ？と思ったら、意外にもswitch文に関する設定がありませんでした。困った。

（※）IntelliJ IDEA 14の自動インデントの設定は、メニューのFile - Settingsを選び、左側のツリー表示からEditor - Code Style - Javaにあります。種別としてはIndentに相当するはずですが、switch文について言及されている項目は1つもありません。

無理やり設定する

インデントの違いは非常に些細なことですが…、個人的に見た目が受け付けないのと、今まで書いてきたコードのインデントがことごとく変わり、バージョン管理システムが差分を大量に表示するので、うっとおしいのです。

前述のようにGUIから設定する方法はなさそうなので、ひとまずGUIからの設定は諦めました。代わりに自動インデントの設定ファイルを直接書き換えようと思います。

まず、自動インデントの設定（メニューのFile - Settings、左側のツリー表示からEditor - Code Style - Java）を適当に書き換え、適当な名前、例えばDefault(1) という名前で保存します。するとC:\Users\username\.IdeaIC14\config\codestyles\Default _1_.xmlという設定ファイルができます。

その後、起動しているIntelliJ IDEA 14を全て終了させて、Default _1_.xmlの設定を直接書き換えます。下記の★部分を追加してください。

<code_scheme name="ConfigName">
  ...
★  <codeStyleSettings language="JAVA">
★    <option name="INDENT_CASE_FROM_SWITCH" value="false" />
★  </codeStyleSettings>
</code_scheme>

設定を書き換えたら、IntelliJを再び起動してください。するとswitch - case文の内部が自動インデントされなくなります。

批判なのか評論なのか見分ける方法（試行中）

仕事でもプライベートでも、自身の行いや意見に「それは○○の理由でだめ、△△すべき。」のように批判もしくは評論されることがあると思います。

昔は意見の扱いに困っていましたが、最近は、なるほど正論だな〜と思ったら、
「ご意見ごもっともです。では一緒にやりましょう。私は（半分くらい）やります、あなたは（半分くらい）をやっていただけませんか？」
と返すようにしています。

というのは、この後「やる」か「やらない」か？を見れば、その意見が「批判＋提案」なのか「評論」なのかが、割とキッパリと分けられる気がするからです。

• 「やる」人は、半分やってくれる、具体的な分担、時期、適切な協力者の紹介など、提案してきた内容を実施します。
• 「やらない」人は、いつかやると言ってウヤムヤ、全部押し付けてくるなど、提案してきた内容を絶対に実施しません。

この法則が合っているかどうか、しばらくこの返しを続けてみようと思います。

メモ: 技術系の話はFacebookから転記しておくことにした。

Amazonの不思議な注文確認メール

目次: Kindle

今だけなのか昔からなのかわかりませんが、Amazonポイントを使って購入すると、注文確認メールに</tr>と入ったメールが来ます…。何これ。通常の買い物では特に異常はないです。

商品の小計:                                  ￥514
Amazonポイント：                                        -￥86
        </tr>
                                              ........................
注文合計:                                    ￥428

システムも生き残りたい

ライブラリの守備範囲は狭い方がいい - Konifar's WIP を読んで。

リンク先の記事に同意です。可能な限り1つのモジュールは1つの課題にフォーカスし、規模もできるだけ小さくすべきだと思います。

システムは人が作るものですから、人と同様「より長く、より広く生きて（＝使って）ほしい」という思いが根底にあるはずで「時代に合わせて変われないものから滅びる」という生物の摂理には逆らえないだろう、という考えでいます。

モジュールのフォーカスを狭めたい理由として「開発の参入障壁を下げて、変更のチャンスを増やす」「規模を小さくして、変更コストを下げる」を挙げたいです。

何でそうしなきゃいけないと思うか？は人によるし、正解も間違いも無いと思いますので、他の方の想いも聞いてみたいところですねー。

メモ: 技術系の話はFacebookから転記しておくことにした。