2012年11月28日水曜日

Sublime Text 2 でファイル保存時に自動でビルドさせる

Sublime Plugin を作ってくれている人がいました。
https://github.com/alexnj/SublimeOnSaveBuild

とりあえずは git clone していれてみる。

git clone https://github.com/alexnj/SublimeOnSaveBuild.git

できた SublimeOnSaveBuild フォルダを Sublime Text 2 のパッケージディレクトリ([Preferences] → [Browse Packages...])にコピー。

そうすると
[Preferences] → [Package Settings] → [SublimeOnSaveBuild]
ができる



ここの [Settings - Default] をみると次のようになっている

{ "filename_filter": "\\.(css|js|sass|less|scss)$", "build_on_save": 1 } build_on_save は 1 のとき、保存時に自動でビルドする。
filename_filter は保存時にビルドを走らせるかどうか判断するファイル名の正規表現。

デフォルトでは .ts がないですね。
TypeScript (.ts ファイル)でも保存時にビルドさせたいので [Settings - User] を作ります。
(注:[Settings -Default] は変更してはいけません)

[Preferences] → [Package Settings] → [SublimeOnSaveBuild] → [Settings - User] を選択肢し、以下を書いて保存する。

{ "filename_filter": "\\.(ts|css|js|sass|less|scss)$", "build_on_save": 1 }

わーい Ctrl (Command) + B でビルドも走るようになったー!


Sublime Package Control からもインストールできるそうです。


2012年11月27日火曜日

Sublime Text 2 で TypeScript をビルドする

Sublime Text 2 に TypeScript の Build System を作ります。

[Tools] → [Build System] → [New Build System...]

TypeScript.build-system という名前で以下を保存
(パッケージフォルダのしたの User/ の保存される)

{ "cmd": ["tsc","$file"], "file_regex": "(.*\\.ts?)\\s\\(([0-9]+)\\,([0-9]+)\\)\\:\\s(...*?)$", "selector": "source.ts", "osx": { "path": "/usr/local/bin:/opt/local/bin" }, "linux": { "path": "/usr/local/bin:/usr/bin" } } TypeScript でのビルドを明示したいなら、[Tools] → [Build System] → [TypeScript] を選択する。
Auto のままでも拡張子が .ts なら TypeScript でビルドされる。

[Tools] → [Build] もしくは Ctrl (Mac は Command) + B でビルド



var を ver とタイポしたときのエラー表示



file_regex は tsc のエラーの正規表現にする。



解説は以下↓


Build Systems

Sublime Text には、外部のプログラムにファイルをかませる機能があります。

独自の Build System を作るには以下のステップを行います。
  • オプション : 外部の実行可能ファイル(スクリプトやバイナリファイル)を用意する
  • .sublime-build という拡張子の設定ファイル(JSON 形式で記述する)を用意する
  • ビルドを開始する Sublime Text のコマンドを用意する
デフォルトでは build systems は Packages/Default/exec.py に実装されている exec コマンドを使います。このコマンドをオーバーライドすることができます。

.build-system ファイルの例 { "cmd": ["python", "-u", "$file"], "file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)", "selector": "source.python" }

オプション
  • cmd
    実行するコマンドと必要な引数が入った配列。
    フルパスを指定しなかった場合、システムの環境変数 PATH から外部のプログラムが検索される。

  • file_regex
    オプション。
    cmd のエラー出力をキャプチャするための正規表現。

  • line_regex
    オプション。
    もし file_regex が現在のラインとマッチせず、line_regex が存在して現在のラインとマッチするなら、file_regex とマッチするラインが見つかるまでバッファ使って遡り、これら2つのマッチを使って進むべきファイルとラインを決定する

  • selector
    オプション。
    [Tools] → [Build System] → [Automatic] が true にセットされているときに利用される。
    Sublime Text はアクティブな View 用の適切な build system を見つけるためにこのスコープセレクターを使う。

  • working_dir
    オプション。
    cmd を走らせる前に変更するカレントディレクトリとして変更するディレクトリ。
    元のカレントディレクトリは後でリストアされる。

  • encoding
    オプション。
    cmd の出力エンコーディング。有効な python エンコーディングでなければならない。デフォルトは UTF-8。

  • target
    オプション。
    実行する Sublime Text コマンド。デフォルトは exec (Packages/Default/exec.py)。

  • env
    オプション。
    現在のプロセスの環境変数が cmd に渡されるまえに、現在のプロセスの環境変数にマージされる環境変数の Dictonary。

  • shell
    オプション。
    true の場合、cmd は shell を介して実行される。

  • path
    オプション。
    cmd が呼ばれる前に、現在のプロセスの PATH がこの文字列に置き換わる。
    元の PATH の値は後でリストアされる。

  • variants
    オプション。
    メインの build system のオプションを上書きするオプションの Dictionary のリスト。

  • name
    variants の内部でだけ有効。
    variant build system を識別する。
    name が Run の場合、variant は Tools | Build System メユーの下に表示され、Ctrl + Shift + B がバインドされる。


プラットフォーム独自のオプション
  • windows
  • osx
  • linux
{ "cmd": ["ant"], "file_regex": "^ *\\[javac\\] (.+):([0-9]+):() (.*)$", "working_dir": "${project_path:${folder}}", "selector": "source.java", "windows": { "cmd": ["ant.bat"] } }

Variants

{ "selector": "source.python", "cmd": ["date"], "variants": [ { "cmd": ["ls -l *.py"], "name": "List Python Files", "shell": true }, { "cmd": ["wc", "$file"], "name": "Word Count (current file)" }, { "cmd": ["python", "-u", "$file"], "name": "Run" } ] }

Build System の変数
  • $file_path
    現在のファイルのディレクトリ 例) /Files/
  • $file
    現在のファイルのフルパス 例)/Files/File.txt
  • $file_name
    現在のファイルの名前 例) File.txt
  • $file_extension
    現在のファイルの拡張子 例) .txt
  • $file_base_name
    現在のファイルの名前部分 例) File.
  • $packages
    パッケージフォルダへのフルパス
  • $project
    現在のプロジェクトファイルへのフルパス
  • $project_path
    現在のプロジエクとファイルのディレクトリ
  • $project_name
    現在のプロジェクトファイルの名前
  • $project_extension
    現在のプロジェクトファイルの拡張子
  • $project_base_name
    現在のプロジェクトファイルの名前部分


Build System を実行する

[Tools] → [Build System] から実行したい build system を選択して、[Tools] → [Build] を選択するか Ctrl (Command) + B を押す。



Sublime Text 2 に TypeScript の syntax highlighting を入れる

Interoperability @ Microsoft MSDN Blogs - Sublime Text, Vi, Emacs: TypeScript enabled!
で Sublime Text のアイコンをクリックして zip ファイルをダウンロード

展開すると
  • README-sublime-typescript.txt
  • typescript.tmLanguage
が得られる

Sublime Text の syntax highlighting の作り方は
http://docs.sublimetext.info/en/latest/extensibility/syntaxdefs.html
にあり、自分で作成する場合は以下のようにするが、

JSON 形式で記述
 ↓
.tmLanguage ファイル(XML形式)に変換する

上記のエントリでは .tmLanguage の状態のものを提供しているので、Sublime Text を起動して [Preferences] - [Browse Package...] で開くフォルダ(私の場合(Ubuntu)は ~/.config/sublime-text-2/ だった)に TypeScript フォルダを作成し、そのなかに typescript.tmLanguage ファイルをコピーして Sublime Text を再起動すれば OK.


2012年11月22日木曜日

Ubuntu に Sublime Text 2 をインストールした

Sublime Text 2 の Ubuntu 用 PPA みつけた

WEB UPD8 - SUBLIME TEXT 2 UBUNTU PPA
> sudo add-apt-repository ppa:webupd8team/sublime-text-2
> sudo apt-get update

> sudo apt-get install sublime-text


> sublime-text -h
Sublime Text 2 Build 2217

Usage: sublime_text [arguments] [files]         edit the given files
   or: sublime_text [arguments] [directories]   open the given directories

Arguments:
  --project : Load the given project
  --command : Run the given command
  -n or --new-window:  Open a new window
  -a or --add:         Add folders to the current window
  -w or --wait:        Wait for the files to be closed before returning
  -b or --background:  Don't activate the application
  -h or --help:        Show help (this message) and exit
  -v or --version:     Show version and exit

Filenames may be given a :line or :line:column suffix to open at a specific
location.

> sublime-text -v
Sublime Text 2 Build 2217
-v でビルド番号はでるが、バージョンはでないのか。。。

2012年11月21日水曜日

Ubuntu に Typescript をインストールした

Synaptic Package Manager で
  • npm
  • nodejs
をインストール

> npm install -g typescript
すると
npm ERR! couldn't read package.json in .
npm ERR! Error installing .
npm ERR! Error: ENOENT, No such file or directory 'package.json'
npm ERR! Report this *entire* log at 
npm ERR! or email it to 
npm ERR! Just tweeting a tiny part of the error will not be helpful.
npm not ok

と言われる。

どうもインストールした npm のバージョンが古かったようだ

github : isaacs / npm - couldn't read package.json in .

1.x をインストールしないといけないらしい
Synaptic から入れた node.js も古かった

ということで node.js と npm を一旦アンインストールし、コメントの最後のほうで isaacs さんが紹介している https://launchpad.net/~chris-lea/+archive/node.js/ からインストール

そのためにまず ppa:chris-lea/node.js を PPA(Personal Package Archive) に追加

> sudo add-apt-repository ppa:chris-lea/node.js

You are about to add the following PPA to your system:
 node.js
 Evented I/O for V8 javascript. Node's goal is to provide an easy way to build scalable network programs
 More info: https://launchpad.net/~chris-lea/+archive/node.js
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpIBxqM3/secring.gpg' created
gpg: keyring `/tmp/tmpIBxqM3/pubring.gpg' created
gpg: requesting key C7917B12 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpIBxqM3/trustdb.gpg: trustdb created
gpg: key C7917B12: public key "Launchpad chrislea" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK

> sudo apt-get update
次に node.js と npm をインストール

> sudo apt-get install nodejs
> sudo apt-get install npm

> npm -v
1.1.65
よしよし

ようやく

>  npm install -g typescript
npm http GET https://registry.npmjs.org/typescript
npm http 200 https://registry.npmjs.org/typescript
npm http GET https://registry.npmjs.org/typescript/-/typescript-0.8.1.tgz
npm http 200 https://registry.npmjs.org/typescript/-/typescript-0.8.1.tgz
npm ERR! Error: EACCES, mkdir '/usr/lib/node_modules'
...
キターとおもったらエラー orz

> sudo npm install -g typescript
npm http GET https://registry.npmjs.org/typescript
npm http 304 https://registry.npmjs.org/typescript
/usr/bin/tsc -> /usr/lib/node_modules/typescript/bin/tsc
typescript@0.8.1 /usr/lib/node_modules/typescript
はいったぽい?

Tutorial のコードを書いて

> cat greeter.ts 
function greeter(person) {
    return "Hello, " + person;
}

var user = "Jane User";

document.body.innerHTML = greeter(user);

> tsc greeter.ts 
怒られなかったー

> ls
greeter.js  greeter.ts
js ファイルできてるー



2012年11月20日火曜日

Simple でいつづけるには強い意志と努力が必要だ。エントロピーに逆らわないといけないからね。

「Think Simple」読んだのでその感想とか。

著者のケン・シーガルさんはアップルの広告代理店としてさまざまな広告やキャンペーンを担当された方です。

事例集というか、ある意味ジョブズの伝記として読み物として面白い。
ただし、言いたい事は Conclusion にまとまっているので、要点を抑えたいだけならそれを読めば十分ではある。
あるが、読み物として面白い。


・Think Brutal 容赦なく伝える

お互いオブラートに包んだ物言いで、相手の真意を推測しあうのは無駄。
チーム内で思った事は率直に伝えよ。

(私はお世辞が苦手というか言えない人です。空気もあんまり読めないし、気を使うのも苦手です。メールに本件と関係ない挨拶を入れるのも嫌いです。この項目はクリアしてるはず)


・Think Small 少人数で取り組む

- ただの少人数ではなく、有能な少人数のグループで取り組む。

(本書のなかでジョブズは会議に参加していた女性に「君は誰だ?」といい、議論する予定のプロジェクトに関わっているので参加するように言われました、と答えた女性に「この会議に君は必要ない、ご苦労様。」と言ったわけだが、参加者自身が必要と思っているならまだしも「オレこの会議に出る必要なくない?」と思いながら参加させれられている会議ほど無意味なものはないわけです。
後々関わるかも、利害関係的に参加させないとあとでうるさい、などの理由で参加者が決まっているようではやばいってことですよね。)

プロジェクトの成果の質は、そこにかかわる人間の多さに反比例する

- 最終的な意思決定者がちゃんとした形で参加しないプロジェクトは何であれ疑ってかかれ。

(意思決定者が最後の最後にふらっときてイエスかノーかをいうだけなら、イエスを言われるように無難で(欠点はないが尖ってもいない)平凡な結果になるだけ)

プロジェクトの成果の質は、最終的な意思決定者がかかわる程度に比例する


・Think Minimal ミニマルに徹する

大量の選択肢は選択肢がないことと同じだ。

(本書では、ジョブズがアップルに復帰したときにコンピュータのモデルを膨大な数から 2x2 の 4種類にしぼったことを取り上げており、対比としてデルの製品ラインナップ数の多さに言及している。一度増えた製品ラインナップを減らすのはなかなか難しいことだと思う。最近のスマホの機種数爆発はすごいですね。HTC とか Xperia とかありすぎて私にはもうなにがなんだかわかりません。)


・Think Motion 動かし続ける

偉大なことをなし遂げるには、ふたつのことが必要だ。計画と、十分ではない時間だ。

(もたもたすんな、さっさとやれ。余計なプロセスを増やすな。)

プロジェクトでは、少し時間が足りないのが理想的なスケジュールだ。


・Think Iconic イメージを利用する

(ジョブズが復帰してから iMac を発表するまでの間に行われた「Think different」キャンペーンについて取り上げている。まだ(復帰してから)なにも製品を出していないし倒産寸前だったのに、ブランド確立キャンペーンを行った(つまり投資をした)のは普通に考えればクレイジーである。p137 の「ジョブズの考えるマーケティングとは」は一読する価値あり。)


・Think Phrasal フレーズを決める

(iMac の命名についての話。著者は iMac の名付け親。ジョブズは最初マックマン(MacMan)を推していた。製品やその製品の機能とは全く関係ない中二病みたいな名前じゃなくて、もっとわかりやすい名前にしろよということ、例外は「ドロイド」だそうだ。)

「汝、隣人のマーケティングを望むなかれ」

(ファイナルカット・スタジオ2をリリースするときに、Adobe のようにさまざまなエディションを用意したほうがいいと提案したプロジェクトメンバーの1人をジョブズが一刀両断する話。)

多くのライターは意識したことがないようだが、知的な言葉を使ったからといって、かならずしもその人が賢く見えるわけではない。人や会社をスマートに見せる最良の方法は、完璧な明快さでアイデアをシンプルに表現することだ。

(わかりやすく説明するのはすごく大変だけど、その価値はある)


・Think Casual カジュアルに話しあう

(ジョブズが新しいプランナーのプレゼンテーションに対して怒った話。そもそもプランナーに Apple のブランド監査をさせたという事自体が、大手広告代理店のスタイルを重視するふるまいであり、そういう代理店をジョブズが嫌っていたから怒った。プランナーのプレゼンテーションがいまいちだったというのもあるだろう。3つの文章でいえることを20枚のスライドで見せられたらジョブズじゃなくてもうんざりすると思う。)


・Think Human 人間を中心にする

そもそもアップルが成功してきたのは、人間の価値観を反映する製品を作っているからだ。

(iMovie の CM の話とか、NeXT の話とか、スタンフォード大学の卒業式でのスピーチの話とか)

ジョブズの3つの挫折
・アップルを追い出されたこと
・NeXT で成功を収められなかったこと
・自分の死に直面したこと

「死は人生が生みだした唯一にして最上の創造物だと思われるからです。それは人生に変化をもたらす因子です。死は古いものを一掃して新しいものへの道をひらいてくれるのです。」
by スタンフォード大学の卒業式でのスピーチ

(本当に余命宣告される状況にならないとなかなか意識するのは難しい。。。)


・Think Skeptic 不可能を疑う

同僚や取引先がノーと言ったときに、あなたは額面どおりに受けとらないほうがいい。かなりの場合でそれは、非常な努力が必要か、いつものやり方と違うか、とてもコストがかかる、といった意味にすぎない。

「他人の意見によって、自分の内なる声を溺れさせてはならない。何よりも大切なのは、自分の気持ちや直感に従って行動する勇気を持つ事です。」
by スタンフォード大学の卒業式でのスピーチ

(アップルストアを作るときの話とか)


・Think War 戦いを挑む

(いろんなところに喧嘩を売る話。ライバル(インテルだったりマイクロソフトだったり Windows を搭載した PC だったり)を揶揄した広告とか CM とか。)



あんまり広告詳しくないので、本書で出てきた CM の youtube のリンクを貼ってみます。

「1984年」

「Think different」



ナレーションはリチャード・ドレイファスだが、じつはジョブズのナレーションも当時録音してあった。


「Mac とパソコン」

Mac と PC を擬人化した CM あったわー。
全部の種類覚えているわけじゃないけど。



あ、ラーメンズさんが芸人だって知りませんでした。
アメリカの CM では二人とも俳優さんだったみたいです。


「iPod の CM」

最初の iPod の CM はシルエットじゃなかったため、踊ってる青年がすごいマヌケに見えるということで、ウェブでは「iClod」(マヌケ)なコマーシャルと評されることもあったそうだ。









2012年11月18日日曜日

Android ループできる ViewPager (完全版)作った

LoopViewPager

github : yanzm/LoopViewPager - https://github.com/yanzm/LoopViewPager

ループできる ViewPager です。
(Loop ViewPager, Looping ViewPager)

以前に How to create looping ViewPager というエントリーを書きましたが、不完全だったので、まともなものを作りました。

今回は制限なしです。
Support Package v4 の ViewPager の代わりに使うだけで OK です。
ViewPager から PagerAdapter の package private なメソッドを呼んでいるので、PagerAdapter, FragmentPagerAdapter, FragmentStatePagerAdapter は LoopViewPager と同じパッケージにあるやつを使ってください。

r11 の Suppor Pakcage v4 の ViewPager のコードをベースに変更しています。
PagerAdapter を継承したアダプターの使い方は今まで通りです。

使い方 <com.uphyca.android.loopviewpager.LoopViewPager xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" android:id="@+id/pager" android:layout_width="match_parent" android:layout_height="match_parent" /> public class MainActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); LoopViewPager pager = (LoopViewPager) findViewById(R.id.pager); pager.setAdapter(new MyFragmentStatePagerAdapter(getFragmentManager())); pager.setAdapter(new MyPagerAdapter()); } class MyFragmentStatePagerAdapter extends FragmentStatePagerAdapter { public MyFragmentStatePagerAdapter(FragmentManager fm) { super(fm); } @Override public Fragment getItem(int position) { return SimpleFragment.newInstance(position); } @Override public int getCount() { return 10; } } }

2012年11月13日火曜日

「よりよいコードを求めて命名について頭をひねる会」のログ

http://www.zusaar.com/event/438105

アプリケーションを作る英語 の著者の西野さんを交えて、クラス名とかメソッド名とか変数名とか命名で困っている課題を1つ以上持ち寄りみんなで一緒に検討する勉強会をしました。

「アプリケーションを作る英語」
電子書籍 http://tatsu-zine.com/books/english4app
http://www.amazon.co.jp/gp/product/4844332848/


はじめに:西野さんからちょっとお話

The Art of Readable Code から第2章と第3章

第2章:名前に情報を詰め込むようにする
どういう情報をつめこむか。
明確な言葉を選ぶ
get は不明確らしい

getPage(url) -> FetchPage(url) や DownloadPage(url)

特色のある(colorful)な言葉を選ぶ
・類語辞典を活用
・いろんなふうに解釈される単語よりも、その意味にしかとれない単語を使う
send -> deliver, dispatch

英語のテクニカルライティング
strong verb を使う(反対は weak verb)

汎用的な名前は避ける

retval だけとか tmp だけとかは良くない
(tmp は本当に短期間だけ使う場合以外は使ってはダメ)

具体的な名前をつける
ServerCanStart() -> CanListenOnPort()

名前に情報を追加する
(名前が長くなりすぎる場合はどうしたらいいのかな?)

・単位のついた値
limit -> max_kbps
angle -> degrees_cw

他の重要な情報を盛り込む
password -> plaintext_password
comment -> unescaped_comment
html -> html_utf8
data -> data_urlenc

頭字語と略語
・プロジェクト特有の略語は良くない
・新加入のチームメンバーがわかるかどうかで略語の使用を判断する

不要な言葉を削除する
ConvertToString() -> ToString()
(メソッドの最初は動詞にしろという、話もあり、、、)

名前の書式で意味を伝える
・アンダースコア、ハイフン、大文字小文字で名前に意味を持たせられる
例 CamelCase, lower_separated, UPPER_CASE


第3章:誤解されない名前をつける

「この名前が別の意味で理解されることはないだろうか?」

filter では、含めるのか除外するのかわかりにくい
select や exclude の方がよい

限界値と範囲の表現(まよったときはこっちがいい)

・max/min : 対象は含む
・first/last: 対象は含む

・begin/end: begin は含むが、end は含まない
未満みたいな英語がないので、end をそういう意味に使おうという著者の提案
(less 〜のようなのはどうなの?)

ブール値の名前
・is, has, can, should など
(is の後が名詞のものは作りやすいが、動詞?助動詞?のときにちょっと悩む)

(誤解されなければ前置詞はなくてもいい?)

使う人の期待に沿う
「get」は軽いアクセサと考える人が多い
getMean() -> すでに計算したものを返すイメージ
computeMean() -> 今からたくさん計算するイメージ
(これはボキャブラリがいるなー)

- get に時間かかるのは想定してない
(即時、副作用があって欲しくない)

i,j,k は許すべきかどうか(forループ)
(for が入れ子になっている場合は i_hoge とかにしたほうがいいらしい)
多重のループをかくとバグを生みやすい

Iteratorを使えばループカウンタによるバグを減らせる
ただし、ループカウンタがほしくなることはある
イテレーターからカウンタが欲しくなることはたまーにある by zaki


作業する場合は動詞からにしてほしい
名詞から始めてもしっくりくるかどうか
ToString は失敗例じゃない? by amedama

getStringValue() の get を省略したがの Obje-C の StringValue() らしい

本の文はここまで


コード補間があるので、長めにしても問題ない
・名前付き引数に追い出す?
・長すぎるメソッド名はdisられるけど、短すぎて情報量が少ないのも困る
・5、6単語くらいまで?



シソーラス
Thesaurus.com http://thesaurus.com
同意語(synonym)と反意語(antonym)が豊富(だが難しい)

Macmillan http://www.macmillandictionary.com/
英語圏で定評ある辞書(だが難しい)

日本語
Weblio英語類語辞典 http://ejje.weblio.jp/english-thesaurus/
日本語で探せるので便利(だがエントリが変な部分も)


一般的な類語辞典は多い
コンピュータ関連の本:「科学技術英語 動詞はこう使え!」
関数やメソッドの命名で役にたちそう

類語辞典以外の方法
大きめの英和辞典では類語の違いを解説していることがある
オンラインであれば Weblio -> コンピュータ関連辞書(研究社 英和コンピュータ用語辞典、マイクロソフト用語集

Mac には最初からわりといい辞書が入っている by muo

英英辞典(言葉の意味を調べるにはいい)

new TOPGATE office なのか TOPGATE new office なのか
かかるものの直前につけたほうがいい
TOPGATE's new office


命名を変えるのもリファクタリング
リファクタリングにはテストも含まれる


フレームワークを作るとき、ライブラリを作るとき、公開されないメソッドを作る時で意識を変える by muo

API として公開しているかどうか、補間しやすいかどうか、レビューされる by zaki
API を作る段階でインタフェースだけ定義して、コード書くときに補間でしぼれるかどうかとかレビューする by zaki

クラス名、インタフェース名、似たようなクラスがあると絞りづらい by zaki

BaseHoge だと Base でいろいろ出てきちゃうので HogeBase にしたい
だいたい3文字(キャメル頭文字)にしたい by vvakame

パッケージ名は可視性に使って、名前のコリジョンには使わない by vvakame

いろんなパッケージに BaseAdapter があるより socket パッケージのは SocketBaseAdapter のほうがいい by vvakame, zaki

socket パッケージにあるのに Socket がつくのは冗長じゃない? by amedama

vvakame は書くほう(書くとき)のタイプ数が少ないほうがいい
SocketBaseAdapter は Socket は冗長と思わない、これが冗長になるなら API の設計が変なんじゃない? by vvakame

IDEのクセに依存しそう

Java は Eclipse に最適化されすぎw by amedama

Server side と Client side で違う言語(ruby と Java とか)
の場合にどうしたらいいのか(?)的なやつに関連するもの
https://github.com/ServiceStack/ServiceStack

JSON とかでつながるくらにしておいたほうがいいんじゃない? by muo



---

「リスナーを登録するメソッドについて」 by esmasui
addListener(), registerListener()
add と register の使い分けがわからない

英語的な意味で

addListener <--> removeListener
registerListener <--> unregisterListener

register は紙にかくイメージ by amedama
register は1個、Listener が複数の場合は add
set は登録するイメージがない by amedama
set のときは1個のイメージ

add というと後ろにコレクションがあって複数追加できるイメージ by zaki
append だとくっついて1個のリスナーになってしまうイメージ

1個 -> setListener
複数 -> addListener
register はなんかエラそう by itog
システムに登録するようなアプリ全体のなにかに登録する場合は register


---

なになにのために〜する
例: updateForGame()
updateGame(Game game)
ゲームをアップデートするのではなく、自分がアップデートする?

そもそもゲームをアップデートするわけではない -> uploadGame(Game game) では?

こういうのを多用しているんだけど、これでいいのかな?

vvakame update For Game? -> わかめがアップデートする

update は他動詞のみ

syncGameStatus() とか by amedama
update だと漠然としている。もっと特定の用途を表すメソッドを使うべきでは。

結論は...
自動詞か他動詞か調べよう!
他動詞の場合は、動詞+目的語(目的語) の形がよいのでは
update は抽象的なので、もっとあいまいじゃない動詞を使おう!

for が入る文を調べたかったら英辞郎とかでワイルドカードを使って、for と組み合わせて検索するのがいいのでは by nishinos
英辞郎で "update for {1}" で検索するなど


----

ここからはファンタジー

SnoreEvent というクラス名はありか?

そもそもこれイベントとなの? by corosuke

よくあるのはEventListenerに登録するときのイベント名によくつかうよね by zaki

「命名で悩んでいる場合、APIの設計がうまくないことがよくある」 by muo

これだけで使い方わかるからいいんじゃない? by amedama
WakeUpEvent と AwakeEvent があって AwakeEvent はいつ呼ばれるの?

ファンタジー終わり


---

チームでのさじ加減むずい by muo

プログラミングについても英語についても共通認識をどこに設定したらいいのか
(さっきいろいろ聞いたので、、、)

G社さんはレビューでチェックしている。常識に外れない程度になっている。
新しい API を作るときは全体の整合性を保つようにチェックする機関がある(らしい?)
コーディングのスタイルガイドがある
https://www.google.co.jp/search?q=google+coding+conventions&aq=1&oq=google+coding+c&sugexp=chrome,mod=1&sourceid=chrome&ie=UTF-8&qscrl=1

google coding conventions などでググれ

http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml


---

コミットログの書き方に悩んでいます by vvakame

なぜそうしたのか、というのを長々と書きたい時に英語力が低いので、
どういうことを書いたほうがいいのかわからない。
自分の中では合理的な理由があるんだけど、日本語ならかけるけど英語だとうまく書けない

箇条書きにしてみてはどう? by nishinos

英語でCommitを書こう
https://speakerdeck.com/pwim/ying-yu-dekomitutowoshu-kou
がよかったよ by muo

コミットが主語になる
(This commit) add...
(This commit) change...

過去形がいいんじゃない派
コミットログのサマリーをとって、バージョンの change log に使えるじゃん

(This commit) added...
(This commit) changed...

進行形で書かれてることがあった、進行形はやめようよ by itog

動名詞もあると思うけどw by amedama


----

isHogeHoge() と canHogeHoge() どっちがわかりやすい? by sobachanko

isAccessible() と canRead() とか
どっちがいいの?どっちも bool が返ってくる。

一般的な英語としてはどっちでもいいと思う。
より口語的なのは can の方。どっちを多くつかっているかによるのでは? by nishinos

The file can read
は英語的にあり(read には読み取れるという意味の自動詞がある)
http://ejje.weblio.jp/content/read
write にも自動詞がある

英語として気持ちいいほうにするか、
既存の API に沿うか
→ プロジェクトでどっちかに統一したほうがいいのでは

File クラスとして
isReadable() と canRead() だったらどっちがいい?


---

語彙を増やす方法がしりたい by zaki

英語力を高める感じ
手っ取り早くだったら、辞書で類語をあたってみるとか

日本で書いてるとカラフル過ぎても伝わらない場合がある
computeMean() の Mean の意味を平均と受け取ってくれない(意味と理解する)ことがある by muo

Chrome のタブの機能が便利

英辞郎はたまにあやしいことがある by nishinos


---

Java のパッケージ名と配下の名前のつけ方 by fkm

何かのオブジェクトの集合体で HogeManager みたいなのを
作りたいときに Manager が曖昧なので他にいい名前ないですかね?

HogeManager がたくさん出てくるのはよくない兆候らしいよ by zaki
(HogeHandler, HogeController とかも)

何かを管理するクラスなら Manager でもいいんじゃない? by vvakame

Manager クラスを分解しないと別の名前にできないんじゃない? by amedama

結論:
いろんな機能を1個のクラスに突っ込んでとりあえず HogeManager はよくない
苦し紛れなら設計を見直すべし
Manager として適切(何かを管理してる?)ならそれもいいんじゃない

データベースとかで読み書きの担当とか排他処理をするのは Manager だと思う by itog


---

登録ボタンに register て付けたいときに長くなったので省略したい
省略してはいけないところといいところはあるのか?

本当は文字を小さくするなどして省略しないほうがいい
昔の文章だと、単語のどこで区切っていいか( - でつなげるところ)は決まっている by nishinos
辞書などでは・で区切っている by zaki

基本的には省略語を使わないほうがいい。
曜日や月の名前もどうしてもスペースが足りない時だけ省略を使う by nishinos

翻訳すると長くなる可能性がどうしてもあるので、アイコンを丁寧につくるのがいい by amedama

国際的に共通化されているアイコンが決まっている
どの程度共通認識が国際的にあるかのレベルがある by amedama

Intel のまとめがあるらしい(?) by zaki


---

自動詞と他動詞の使いかた by yanzm

moveCar() と moveToCar()

class vvakame

vvakame.moveCar()
vvakame.move(Car c)

わかめが車を動かす

vvakame.moveToCar()
vvakame.moveTo(Car c)

わかめが車のところまで移動する

clipRect()
clip()
clipTo()

go と come の使い方
I'm coming とか

run など自動詞と他動詞で意味が変わる単語もあるので要注意 by nishinos


---

sign in みたいな過去形にしにくい単語をどうしたらいいのか by mainyaa

幹になるほうの単語を過去形にするのが一般的
signed in とか by nishinos

一語になってる場合は辞書をみよう!

結論:辞書は友達


---

Android でレイアウトのID名に悩む @itog

結論: XML にコメント書こう!


---

命名の妥協点 by leibun

C言語を書いてます
関数名を決めるのに時間かかってしまう
みんなどこで妥協してるの?

名前と設計は別個に考えられないのでは? by itog
インターナル(public と private の private)なら簡単に決めていいんじゃない? by muo


---

メソッド名に引数名を含ませたい場合前置詞や接続詞ってどうしたらいいの? @corosuke

どの前置詞が自然かというのは、辞書や Google で検索してどういうのが多いのか調べるのかいい by nishinos


---

会場を提供してくれた TOPGATE さんありがとう!
ピザを注文してくれたけいご君ありがとう!