3月
20
2016
2

新サービス「フキダシトーク」リリース

フキダシトークという、吹き出し会話調 HTML/CSS ジェネレータをリリースしました!作ってて色々楽しかったです。ぜひ遊んでみて下さい。

フキダシトーク
Qiita 上に書いた技術解説

サンプル画像
サンプル画像

チュートリアルムービー

Written by Otchy in: Development | タグ: , ,
12月
14
2014
3

Indeed.com の Java コード

10年間Javaを書いていた僕が Effective Java 第2版を読み返して新人に薦められるのかを考えてみたという記事に寄せて、ここ 1 年半くらい働いているIndeed.comの環境をシェアしたら面白いのではないかと思ったので記事を書きました。

Effective Java に対するコメントでは無く、Effective Java に対する、上記記事のコメントに対するコメントです。なので、未読であれば上記記事を先に読んだ方が話が分かりやすいかと思います。

環境で言うと、以下のような環境です。まあ前提が大分違うので、結論も違って当たり前なのですが、そういうものもあるんだと参考にしてもらえればと思います。

  • バージョン管理には git を採用している。
  • 基本自分のメインとなるプロダクトはあるものの、どこのプロダクトにあるどのコードに対しても誰でもコミット・プッシュして、マージリクエストを送って良い (権限としてはマージも可能だけれども、そこは紳士協定。)
  • 1つのプロダクトは平均して3〜4人、色んな人がいじりたがる全社でメインのプロダクトだと、同時 (同じ週) に10人以上がコードをいじる事もある。
  • 全てのプログラマが、Effective Java 的な本を読んでいるわけではないが、素養としては間違いなくそれを使いこなせるレベルにある。
  • 全てのコードは (コメントを消す、import を整理するなどの超基本的なものを除き) 誰かしらにコードレビューをされてからマージされる。
  • プロダクトは jar として利用されるライブラリと、それ自体が war としてウェブアプリになるものとに分かれている。
  • 週 1 以上、頻繁に本番リリースされるので、アジャイル的な開発工程になっている。

項目 1 コンストラクタの代わりに static ファクトリーメソッドを検討する
項目 2 数多くのコンストラクタパラメータに直面した時にはビルダーを検討する

これは相当実践されてるなという感じです。上述の環境からかなり防御的なプログラミングが多く、不変クラスを実現するためにビルダーがよく使われます。
Google Guava とか、Google Protobuf を好んで使っている職場な事もあって、Builder の命名などはそれに習っているので、使う側になった場合もそんなに困ることはありません。

項目 3 private のコンストラクタか enum 型でシングルトン特性を強制する

enum でシングルトンを強制する、というか言語上 enum のシングルトンが保証されている、という理解ですが、シングルトンにするために enum を使うというよりは、enum が適切なシーンでは極力 enum を使っていく事が多いです。

例えば、パラメータとして取りうる値が 3 種類なら、それは 3 種の値を持った enum が妥当だよね、という感じです。String でパラメータを受けるようにしちゃうと、バリデーションのロジックと実際の処理を行うロジックがまぜこぜに “してしまいがち” になるけれど、enum だったらそこは強制的に分かれるし見通しが良いね、とか、ライブラリに渡したり、他のロジックから受け取るときも enum なら “それらの値にしかなり得ないことが保証されている” から安心っていうのもあります。
細かいところだと、必要なところで EnumSet とかを使うとパフォーマンスも有利だしとかまあ色々です。

シングルトン云々の話題からは離れてしまいましたね。純粋なシングルトンでないとどうしてもいけないっていうケースは確かに出会ったことないです。
パフォーマンス上、シングルトンにしておくと有利だからそうする、みたいなケースがほとんどじゃないでしょうか。

項目 4 private のコンストラクタでインスタンス化不可能を強制する

これはケースバイケース。常に private にするなんて窮屈すぎるので、public コンストラクタも普通に使って良いと思ってます。もちろんファクトリ、ビルダーの時は private にして当然ですが、シンプルなクラスだったらそんなに目くじら立てる事もないのかなぁと。DI して interface と implements を切り分けるときはまた別のお話ですね。
まあ過去の経験から言えば、参加するエンジニアのレベルが予測できない場合の防御策としてはありと思います。

項目 5 不必要なオブジェクトの生成を避ける

こういうのは、基本やっておいて損はないのかなと思ってます。特にライブラリ寄りだと、そいつはループの中から呼ばれるかも知れないぜ?っていうのもあるので、不変オブジェクトを static private に追い出すとかは良くやります。昨今、メモリの方が CPU より安いと考えた方が良いケースも多いですし。ただ、Web やってる人はマルチスレッドのことを常に忘れてはいけませんね。

項目 6 廃れたオブジェクト参照を取り除く

同意。こんなん Web サービスで残しておいたら命取りです。

項目 7 ファイナライザを避ける

ファイナライザ?何それ美味しいの?

項目 8 equals をオーバーライドする時は一般契約に従う
項目 9 equals をオーバーライドする時は、常に hashCode をオーバーライドする

ちゃんとやりますよ。equals のオーバーライド自体滅多にやらないですけどね。

項目 10 toString を常にオーバーライドする

いや、これはやらない方がいいんじゃ?toDebugString とか toHtml とか toJsonString とか目的別の名前推奨したいです。

項目 11 clone を注意してオーバーライドする

clone はもうレガシー。ファイナライザくらい何それ (ry という世界な気がします。
それとか、コピーが欲しいクラスでビルダーが採用されてたりしたら、MyClass.Builder.of(instance).build(); 的な感じになったりします。

項目 12 Comparable の実装を検討する

compareTo 実装するなら、equals とか hashCode も一緒に実装したいところですね。

項目 13 クラスとメンバーへのアクセス可能性を最小限にする
項目 14 public のクラスでは、public のフィールドではなく、アクセッサーメソッドを使う
項目 15 可変性を最小限にする

これは最初に書いた現在の開発環境に大きく影響を受けてますが、ガンガンにそうしてます。あとからやっぱ private じゃない方が良かったー!ってなったら、その時に親クラスの方を変えてしまえる環境だからですね。ただ Unit Test を書くための package private (デフォルト) もよく使います。とはいえその時は必ず、@VisibleForTesting アノテーションを付けるようにする、っていうくらい private に出来るものは極力そうするっていう感じです。

項目 16 継承よりコンポジションを選ぶ

ケースバイケースですかねー。個人的には、閉じた単一プロダクトの中では継承。コード全体の見通しが悪くなる外部ライブラリ内のクラスに対しては移譲、っていう使い分けが多いように思いますが、例外もいっぱいです。
そもそも、前述の通りの環境なので、移譲が必要そうになったらライブラリ側に手を入れてそっちで継承させてしまったり、という事もしますし。

項目 17 継承のために設計および文書化する、でなければ継承を禁止する

あぁ、この辺ゆるいですね。いいんだか悪いんだか、昨今の IDE の静的解析が優秀なので、ドキュメントがなくてもソースが簡単に追えるからぶっちゃけ困ってないというか、いやドキュメントがあった方が最初は楽なんだろうけど、それが最新状態とは誰も保証してくれないから結局ソース読むよね、っていう。
その辺を意識してか、全社のコードリポジトリの全文検索エンジンがあったり、jar をリポジトリから依存解決するときに、デフォルトでソースもセットで落ちてくるようになってたり、なるべく少ないコストでソース追えるような環境にはなってます。

まとめ

元記事読んで思ったのは、Indeed の開発環境はやはり防御的だな、という感じです。これまでに働いていた環境ではここまでというのは無かったのですが、まあ慣れてしまえば書くのもおっくうじゃないですし、メリットを享受するだけになるので、そういうスタイルが普通になってきました。
こういうスタイルで書きながらも、高速な開発サイクルを回せてるのはすげぇなぁと思うところです。

そういえば、Java は開発おせーんだよ、Python 使え Ruby 使えだのいう話がありますよね。
でも一方で、じゃあそれらは過酷なパフォーマンス負荷に耐えられるんだっけ?という話もあったり、言語にこだわるよりいわゆる 10 倍速いプログラマ雇うことにこだわった方がいいんじゃない?とか、Java はもはや IDE とセットで一つの言語と言っても過言で無いので、IDE まで含めて考えると言うほど生産性悪くないよ?むしろ静的解析のおかげで、コードベースが大きくなったときは明らかに Java の方が楽だよ?とか色々です。
トータルで見るとまだまだ Java の牙城は揺るがないのかなぁと思います。

Effective Java の話に戻ると、なんだかんだ今の自分の思考/指向とも合致することが多いので、初学者にも勧めて良い本だなと、元記事と同じ結論になりました。

Written by Otchy in: Development |
10月
14
2014
2

英語で仕事をするようになって学んだ、日常会話で超便利な英語ベスト5

昨年 5 月から、Indeed というアメリカ (生まれ) の会社でエンジニアとして働かせてもらっているのですが、これまで約 1 年半英語で仕事を続けてきた中で、これは便利だなー、と感じた英語表現があるので、ランキング形式でまとめてみました。

自分の置かれている環境的に、アメリカ的な英語なのだと思ってますが、他の英語圏とかでも同様によく使われてるのかはわかりません。また、かなりカジュアルなシチュエーションを想定してます。その辺りは留意して下さい。
もちろん、この部分おかしいよ、他にもこういうのあるよ、イギリス英語だとね、などなど色々突っ込み歓迎です!

第5位 say

辞書の上の方にある、「言う」という意味じゃなく、かなり下の方にある、「例えば…」とか「仮に…」という用法の方です。これ、頻繁に聞きます。
「例えば」というと、”for example” って言いたくなるし、実際それもよく聞くんですが、会話の中ではよく “say” も使われます。

(例)
「で、これを A として…」
 → “So, say this is A, then…”
「ここに 3 本の矢があるとするじゃろ?」
 → “(let’s) say there’re 3 arrows.”

第4位 work

「働く」ではなく「機能する」の意味の方ですが、これが想像以上に広く使えて、意味が通るみたいです。日本語でぴったり一語に翻訳するのは無理じゃないかと思います。
「いいよ」とか「問題なし」とか、ともかく何かうまくいってるよ、みたいなニュアンスですね。

(例)
「土曜か日曜かどっちならこれる?」「あー、日曜かな」
 → “Which day could you come? Saturday? Or Sunday?” “Ah, Sunday works.”
「これでいい?」「うん、いいよ」
 → “Does it work?” “Sure, it does.”

第3位 mean

この記事を書くにあたって、どう日本語に訳すか悩んだんですが、「つまり」が一番しっくりくる感じの使い方です。
何か説明して、「あ、伝わってないな」とか「しまった、誤解を産みそう」とか、思ったらすかさず “I mean…” と続けます。すると、相手も続きを待ってくれるので、噛み砕いたり、違う方向から説明したりする感じです。
直訳すると「私の意味するところは」とでもなるんでしょうけど、もっとずっと軽い言い回しです。もちろん自分に対してだけでなく、”you” にも使えます。

(例)
「だからアイツはなー。あ、いや(汗)、つまりね…」
 → “That’s why he is — Ah wait, I mean …”
「つまり、どういう事?(もっかい説明お願い!)」
 → “So, what do you mean?”

第2位 so

日本語でそのものずばり「そう」の事です。”I think so.” で、えらい頻繁に聞きますが、「そう」いうシチュエーションでは常に使えます。簡単過ぎて一番ビックリしたやつがこれ↓です。

(例)
「もしそうなら…」
 → “If so …”

第1位 -ish

何でもかんでも -ish をつけてカジュアルに曖昧さを表現しちゃえます。「っぽい」「らへん」「的な」あたりの日本語に相当すると思います。会話とかチャットではしょっちゅう出てくるんですが、ちゃんとした文章では使わない表現なのは間違いないでしょう。

(例)
「7時らへんにやるよ」
 → “I’ll do that at 7-ish”
「すぐ?に始められそう?」
 → “Can we start it soon-ish?”
「うわー、めっちゃ東京っぽい!」
 → “Whoa, that’s really Tokyo-ish!”

番外 make sense

「分かってる」だったり「通じてる」だったり、とりあえず理解してるかどうかを表すときに使われる言い方ですが、この「分かってる」度合を表す表現が多彩で面白いです。

(例)
「通じた?」「ばっちし!」
 → “Does it make sense?” “Totally makes sense.”
「すっげー分かるわ、それ!」
 → “It makes a lot of sense!”
「ワケ分かんないんですけど。」
 → “Completely does NOT make sense.”

以上

かなり便利で、色々と面白かったり、驚いたりした英語表現でした。
ボキャブラリーがプログラミングとか仕事関連に偏りすぎていて、まだまだランチタイムとかさっぱり会話について行けないこともあるんですが、エンジニアやってて良かったなーと思うのは、プログラミング言語を共通語として意思疎通できたりする点ですね。自然言語の文法もあのくらいシンプルで、予約語もあの程度の数ならどんだけ楽なことか…。

Written by Otchy in: English |
12月
13
2013
2

デバッガの条件ブレークポイントで変数値を書き換えるとデバッグが捗る話

自分がよく使う言語が Java と JavaScript というだけで、とりあえず Java と JavaScript にタグ付けしていますが、たぶんそれ以外の言語でも大抵有効なんじゃ無いかという Tips です。

Java ではデバッグに Eclipse と IntelliJ など使っています。JavaScript はほとんど Chrome の Developer Tools です。こういったブレークポイントを設定出来るデバッガでは、ブレークする条件に式を書ける機能を持っている事が多いです。少なくとも例に挙げた 3 つでは可能です。こういう条件付きブレークポイントで、最初に思いつく使い方は例えば以下のような物ですね。

for (int i=0; i<len; i++) {
  // 条件付きブレークポイント [i % 3 == 0]
}

変数 i が 3 の倍数の時だけ挙動が変、みたいなバグをデバッグするときに有効です。そして本来の使い方なのだと思います。

さあ、ここからが本題です。

テスト時とかデバッグ時とかに、一時的にこのフラグを変更したい、この変数値を書き換えたい、等々ありますよね。こういう時もデバッガは有効で、いったんブレークした後にメモリ上の変数を書き換えてそのまま実行するなどして、挙動を確かめることができます。

ただ、同じ条件で何度かテストしたいのに、毎回これをやるのは面倒です。ソースをちょっと書き換えちゃいます?まあ良いですが万一消し忘れたら大変ですし、そもそも外部ライブラリの部分だったりしたらもっと面倒ですよね?

そこで条件付きブレークポイントです。

boolean flag = checkSomething();
if (flag) {  // 条件付きブレークポイント [(flag = true) == false]
  // 何かテストしたい処理
}

なんとこれだけで、ブレークポイントを通過するときに、flag が常に true になります。そこでブレークすること無しに、です。しかもブレークポイントの有効・無効を切り替えることで、挙動の切り替えも可能です。
たったこれだけの事ですが、使い慣れるとウルトラ便利で、デバッグの度に大活躍してます。このハックが誰かの役に立つことを祈っています。

Written by Otchy in: Development | タグ: ,
7月
14
2013
2

デジタルネイティブの次の世代・タッチネイティブの話、あるいはスキュアモーフィズムについて

もう何年か前だと思うのですが、紙の雑誌の写真を触ってピンチアウトしようとする小さな子供 (むしろ赤ちゃんに近い) の動画が話題になった事がありました。
それとか実体験としては数ヶ月前、MacBookAir を選びに子連れでショップに行ったら、娘 (5歳) はまず最初に Air のディスプレイを触って動かそうとしてました。

また娘は、ひらがなの読み書きを覚えてア行〜ワ行の概念を理解するのとほぼ同時に、フリック入力も出来るようになりました。長押しで周りにイ〜オ音のひらがなが表示されるというのが重要で、ベル打ち、ましてやローマ字入力ではあり得なかった話です。

そこに来て、このニュース。
約2割の2歳児が「ほとんど毎日」スマホ使用 (オリコン) – Yahoo!ニュース

産まれながらにデジタルガジェットに囲まれて育ち、デジタルに対する先入観無く使いこなす世代をデジタルネイティブなどと呼びますが、もはや次の世代はデジタルネイティブなのは当たり前すぎて言うに及ばず、タッチネイティブと呼ぶべき世代ではないでしょうか。

おおよそ今の 3〜5 歳は、ディスプレイというディスプレは触って操作できて当たり前という認識を持っているように思います。そういえば街中で見かけるディスプレイも、券売機だったり、デジタルサイネージだったり、タッチできるようなものが多くなりました。

実装の容易さから今はタッチ UI が主流ですが、タッチ UI を含むナチュラルユーザインターフェースについても、このタッチネイティブ世代は華麗に使いこなしていくんだろうなぁと予想しています。ジェスチャー入力も、音声入力も、出来て当たり前の環境に育てば、それはそういうものだと認識するはずです。

折しも iOS7 の発表に前後して、フラットデザインとスキュアモーフィズムの事が取りざたされる事が増えていますが、実在する物のデザインを模倣することで意図する機能を伝えるスキュアモーフィズムという考え方は、もはやタッチネイティブの前では通じません。

すなわち彼らにとって実在するディスプレイという存在が、触れる物であり押せる物であり書ける物だからです。何かのデザインを真似る必要など無いのです。オールドタイプな我々が、紙とペンを文字を書く道具であると認識するのと同じように、彼らはディスプレイをそのように認識します。

そういえば娘の話に戻ると「電話は電話でも写真が撮れない電話はな〜んだ?・・・答えは家の電話でしたー!」というなぞなぞを出された事があります。何のことはないよくある子供のなぞなぞ遊びですが、彼女にとって電話とは写真が撮れることが普通なのだとびっくりしました。産まれてからずっとそういう物しか見なければ、そういう認識になるのは当たり前ですよね。

漫画とか映画とかで現代にやってきた未来人が「コンピュータ!」とデバイスに話しかけて笑いを誘うシーンは、未来のタッチネイティブが骨董市で見かけた MacBook に対して行う実際の出来事になるのかも知れません。

Written by Otchy in: Lifestyle, Technology |

Powered by WordPress | Aeros Theme | TheBuckmaker.com