サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ドラクエ3
www.artonx.org
_ 驚異のAndroidを支える技術〈I〉 有野さんから滿を満たして出版された「Androidを支える技術〈I〉」をいただいて読み始めた。現在1/2を少し超えたところまで読んだところだけど、今書けることは今書いておく。 結論としては、信じがたくおもしろいからすぐ読むべきだ。 副題は60fpsを達成するモダンなGUIシステムとなっていて、fps（秒あたりの画面書き換え回数）が押されているので、ゲームとかの話かと思ったら、まったく違って、Androidがどういう仕組みでデバイスに対する入力を遅延なくウィンドウの描画へつないでいるかの解説に近い。 そのために利用しているプライオリティ（というか、発火時間順）に基づくイベントのキュー（これがシステム全体としてデバイスからの吸い上げと、アクティブなプロセス内でのイベントの、大きく2つある）と、それをいかに抽象化して実装しているかの解説が、1/2読み終
_ 業務と機能（システムエンジニアというお仕事） ちょっと絵を書いてみた。用語はおれさま用語なので違う言い方があればそれは知りたいし、カテゴライズについて異なる見方はいくらでもあると思う。 意見はツッコミまたはメンションでどうぞ。 で、上の絵の「2.支援」「4.分析」についての本が、はじめよう！プロセス設計。 はじめよう! プロセス設計 ~要件定義のその前に(羽生 章洋) で、上の絵の「5.業務設計」と「6.支援」についての本が、はじめよう！要件定義。 はじめよう! 要件定義 ~ビギナーからベテランまで(羽生 章洋)
_ マイクロサービスアーキテクチャを購入 昨晩は池袋ジュンク堂で高橋さんの2017年版このコンピュータ書がすごいに参加。 いろいろ買ったが（やはりドンカルロス スペインの皇子は無いな）、コンピュータ書では取り上げられていたマイクロサービスアーキテクチャを購入。 この2〜3年ほど、いつの間にか作られていた野生のマイクロサービス相手にいろいろ手直ししてきたが、あまりのひどさにここ数ヶ月で新規に設計し直して実装し直している。 おれの設計はどう考えても理に適っているし正しいが（必ずしも美しくはない）、そうはいっても世の中の趨勢とかけ離れているような見識や業界の狭さに起因する設計バグがあるかも知れないな、と考えたからだ。 そもそも野生でそのへんをうろついているくらいに、マイクロサービスは、分散システムではむしろ自然な実装形態となる。 問題は、依存性（実行時のDIとかだけではなく、設計レベル、仕様レベ
_ メタプログラミングについてのメモ メタプログラミング、日本語で書けば超プログラミング。 最初に「超」を強く意識させられたのは、大学2年の一般教養の数学だ。 なぜか受講するのがおれ1人だったので、教授が初日にあきれたのか、1冊の本を買えと言ったかくれたのか覚えてないが、読んで出席して質問しろ形式となった。 それが数学から超数学へだった。 数学から超数学へ―ゲーデルの証明(E.ナーゲル) 超数学は、数学を斜め上（「斜め」の部分はレトリック）から研究する学問だというのは読み始めてすぐにわかる。数学という学問がどのようなお膳立てで成り立っているかを解明することにある。いずれにしても、メタに考えるには常に「上から目線」の立場に自分を置くべきだ。「上から目線」で語れるということは実に良いことなのだ。 メタプログラミングの場合、それはプログラミングを斜め上からプログラムすることになる。 ちょっと前ま
_ はじめよう! プロセス設計を眺めて 技評の細谷さんから羽生さんの「はじめよう! プロセス設計」を頂いたのでパラパラ読んだ。 とにかく図が多くて、明解だ。 ターゲットはビジネスプロセスを明らかにすることにある。そのために図を使いまくって仕事（語り得ぬもの）をプロセス（語り得るもの）に落とし込んでいく。 そうやって明らかになったビジネスプロセスはシステム化の射程に入る。(何気なくあとがきを読んだら、まさにそう書いてあった) はじめよう! プロセス設計 ~要件定義のその前に(羽生 章洋) ビジネスプロセスと言えば、以前Enterprise Architecture Using the Zachman Frameworkを読んだのを思い出した。 「はじめよう! プロセス設計」を読めば上位2層（最上位のスコープは自然とカバーされるので）については十分と思う（体感としての規模感）。 Enterpr
_ バトル用ポケモンの組み方 現在のジム状況はCP2000越えのカイリューやカビゴンが主流となっている。 ここで問題となるのは、相手チームのジムに対する攻撃ではなく、自チームのジムに対する道場破りだ。（相手チームはとにかく全滅させれば良いので、こちらも高CPのカイリューを用意してひたすらタコ殴りすれば良い） 例として、レベル3で既に3頭が置かれている自チームのジムに自ポケモンを配備する場合を考える。 素の状態のレベル1のジムの名声は1000、レベル2のジムは2000、レベル3のジムは4000なので、これを8000に持ち上げればレベル4となり、自ポケモンが置ける。 今、ジムにはCP500のカメール（多分、置いてみたかったのだろう）、1900のギャラドス、2000のシャワーズがいるとする。 ここで、CP2800のカイリューで殴り込みをかけてタコ殴りで突破したとする。 この場合、得られる名声はた
_ C++によるプログラミングの原則と実践(続) なんか精読し始めたら止まらなくなってしまった（ぱらぱら読むのではだめだなぁ）。 この本は抜群に優れているではないか。さすがだぜストラウストラップ。 というわけで、続き。 第3章の練習問題4は間違っている。 誤）「整数値を1つ入力させるプログラムを記述する」 正）「整数値を2つ入力させるプログラムを記述する」 第4章の「コンピュテーション」はおそらく白眉だ。ストラウストラップ自身が最後のところで、ここで語り尽したみたいなことを書いている（まあ、意味は、プログラムの意味ということについてだけだが）。 しかし惜しいかな、いきなり重要なところを誤訳している。 P.83 4.2. 多分誤）「正しく効率のよいプログラムは複雑であり」 こうでなければおかしい）「正しく効率のよいプログラムであっても複雑過ぎれば」 重要な主張はプログラマーの仕事を、「計算を
_ ポケモンGOに見る中堅企業の人事戦略 さて、中堅企業の人事担当なわけだが（ということにする）、何しろ中堅どころなので社員教育に配分するリソースがない。そこで、採用面接のときに手数料を徴収するようにした。とはいえそれほど悪辣なことはしたくないので、面接に要するコストとして辛うじて赤にならない程度のものだ。 手数料には社会人教育（名刺の受け渡しだの、ビジネスメールの書き方だのどうでも良いことなのに、他社との関係で必要となるもの）用のもの（これを飴と呼ぼう）と、労働者としてのスキルアップの技能教育用のもの（これを星の砂と呼ぼう）の2種類を徴収する。どういう仕組みかわからないが、お祈りメールを書くとお礼に飴が1個余分にもらえることになっている。 採用面接には新卒（進化前）と中途（進化後）が来る。 新卒はたいていレベルが低いので伸びしろが見えない。そこでIQとかEQとかいう良くわからないが個人の
_ ハードコアプログラマのためのハードコアプログラミング入門書 アスキーの鈴木さんからC++によるプログラミングの原則と実践をいただいた。うれしい。 重さ1.9Kg、厚さ4.5cm、ページ数1200越え、お値段は7000円だ。 さすがに、こうなると、今更（おれは既にプロフェッショナルなのだ）おれが自分で購入する本ではない。読み切れないのがわかっているからだ（金額については「今更」ということはなく、むしろ今のほうが手に届くので別の話となる）。 まず、きちんとしたネガティブな評価を見ておこう。 幸い、同じアスキー（ではなくドワンゴのほう）の江添さんが「およそ悪書の見本のような本だ」という完全読破されたうえで結論を出されている。 おれはストラウストラップではないのでどうでも良いのだが、しかし一応、あるべき反論は少ししておこう。 「文章は簡潔にすべし」→それは違う。この本は仕様書ではなく、 ・何よ
_ ポケモンGOの旅をはじめて1か月 ポケモンGOはいろいろな楽しみ方があるという点がおもしろい。 以下、一部以前のメモの内容を含むがこれまで気づいた点を記録する。 とりあえず、ほぼ日課のように、家から駅、地下鉄区間、駅から勤め先の往復、昼間の勤め先周辺（おかげでほとんど昼飯を食わない習慣となってしまった）、夜寝る前はポケモンGOをしている。 1回だけ旅行して、千葉は冨浦の道の駅へ行ったらビリリダマ6匹とコイル2匹に囲まれて、あーこれが「巣」というやつかと思ったが、それを除けば基本的に上で書いたところだけですべてまかなっている。 (コイル1匹とビリリ玉4匹捕まえたところで記念写真を撮ることにした。それにしてもポケストップが無い（近くのスポーツセンターみたいなところに1つある）) その結果、今は次のような構成だ。以下、他人にとってはどうでも良い解説が入る（こういったコレクションオリエンテッド
_ プログラミングElixir この日記の文脈でElixirというと、まず何よりもドニゼッティの愛の妙薬だが、ここではプログラミング言語の名前だ。 笹田さんと鳥井さんが翻訳されたデイブトーマス（どうしてもデイブはただのデブというフレーズを思い出してしまう）の『プログラミングElixir Functional |> Concurrent |> Pragmatic |> Fun 』をいただいた（初稿の校正読みに参加したからだ）ので紹介する。 第3言語としてお勧めして良いと思う(第1言語にはならないという意味ではない。ふつうのソフトウェア開発ではElixirを第1言語にすることはあまり無いだろうなぁという考えからで、第1言語にすることを選択できるのならすれば良いと思う。基盤はErlangなので実績的にも問題ないはずだ)。気に入ったのでおれは第3言語としてはElixirを使うつもりだ。 まず、全部
_ シン・ゴジラ 予告編はスピード感があったし、ゴジラのおっかない雰囲気が出ていてそれなりにおもしろそうだなぁとは思ったが、それだけだったら行かなかったかも知れない。 でも、評判がなかなかよろしいので見に行った（おれは、エヴァの世代にはかすりもしないので（子供がはまると一緒にはまることになったりするので（例：ポケモン）自分が対象世代かどうかはあまり関係ないのだが、とにかくかすりもしなかったので、監督についてもまったくの初見だ）。 すると東宝のオープニングが2重になっていて、昔の東宝が出現して始まった。 まず怒涛のように政府が緊急対策室を設けるまでが描かれる。 すさまじくおもしろい。 ひるがえって考えるに、緊急時の障害対応というのはある意味とてもおもしろい。何が起きているのかを乏しい現場からの情報を元に推測して、予想できる二次障害への対策と発生した場合の対応案を考えながら、大急ぎで修復作業の
_ ある社会科学の実験に対する在英女性3人の視点がおもしろかった UKのEU離脱国民投票が事前の48%離脱52%残留予想から蓋を開けてみたら52%離脱という結果となった。 BBCの結果分析だと離脱勝利の原因は、極端な恫喝に対する嫌悪、福祉予算増額期待、問題のすり替え（移民）、首相の権威低下、労働党の官僚化、ポピュリズム政治家の台頭、老人層（留保つき）、そもそも英国は欧州ではない意識と分析している。 傍目には移民問題に持ち込んだ離脱派の戦略勝ちということになるのだろう。 そこから英国在留邦人の3つの考えがおもしろい。BBCの分析のある特徴のみに特化して裏側から同じことを言っているだけなのだ。 移民は問題じゃなくてサッチャー以来の福祉切り捨てが問題。それが移民問題にすり替わったことが原因。これは正しいと考えて良い。BBCの分析でも問題の「すり替え」≒ポピュリズム政治家の台頭とされている。 移民
_ Unix考古学の夕べ2 銀座松竹タワーのドワンゴセミナールームで、著者の藤田さんによるUnix考古学の夕べ2に参加。 現在はIIJのようで、前ふりは和田英一先生からUnixはどうでもよいけどMulticsについて書いてあるんなら1冊持って来いと言われてあわてて献本したという話から。 で、和田先生からWhirlwind（P.13）はいまも富士通のどこかにあるはずで、当時ゴードンベルが富士通の何かが欲しくてバーターしたはずだとか。 さらに1958年にMITでTX-0（P.15）を見学したが「電動タイプライターによく似た機構のコンソール」とはFlexowriterだったと教わって、さらに1973年にMITで教鞭をとっているときに学生がレポートを印刷して持ってきたので（1973年だよ）一体どうやったんだ？ と尋ねたらTX-0を使ったんだと言われたとか。 で、タイムシェアリングのアイディアは19
_ 成功した失敗プロジェクトと失敗した失敗プロジェクト 高橋さんが『渕一博―その人とコンピュータサイエンス』という本を陰影ある書き方でAIに興味ある人は必読と紹介されていたので、読んでみた。（都立図書館で借りたのだった）とは言っても全部は読んでない。後半、渕の論文集になるのだがたとえば『逆対称声道形の推定と多帯域沪波特性近似』（軽く眺めるとおもしろそうなことが書いてあるけど）とか読む気にはならない。 というわけで興味津々でまともに読んだのは林晋の『情報技術の思想家』という中途半端（とならざるを得ないということが書かれていて、それは生きていて利害関係のある人間のバイアスのかかった証言や反証が出てくることが可能な程度の期間しか過ぎていないものは、歴史として文献ベースで客観的に評価することが難しい壁があるという理由で、なるほどWikipediaが本人による編集を拒むのと同じ理屈であろうし、真実で
_ なぜUnixはUnixなのか（Unix考古学を読み始めた） アスキーの鈴木さんにUnix考古学を頂いたので読み始めて、シェヘラザードの代わりに寝台の脇に置いて何夜か過ぎて大体半分読んだ。 抜群におもしろい。単なる読み物としてもおもしろいのだが、おおそういう理由でそうだったのか/こうなっているのかという説明が（あとがきを読むと、筆者は類書をネタにしているのではなく（ゼロではないだろうけど）、当事者たちのログや論文を読むことで事実関係を掘り起こして推測して結論づけたりしている。なるほど、その作業は電子の地層から掘り起こして塵を払ってつなぎ合わせて当時を復元していく作業にそっくりだ。それで「考古学」なのだな）なかなかに快刀乱麻で読んでいて実に楽しいのだ。 まずまえがきにぶっとぶ。 読み進めて次の文章に腰を抜かした。 人づてに聞いた話だが、著者の藤田氏は1970年代生まれよりも若い年代に本書を
_ tDiary15周年パーティ 渋谷の公園通り入り口のビルの8F（名前忘れたけどドットみたいなやつ）でtDiary15周年パーティ。 最初はたださんの10年後のtDiaryで、えもい話というのでどんなのかと思ったらすごくおもしろかった。センスオブワンダーってこういうことだよな。 ・火星の人の原作は日誌ではなく日記。というのはその日のできごとだけではなく感情が記録されている。 火星の人(アンディ ウィアー) 汎用の人工知能が10年後にはある程度のかたちができているとして、それは何から学習するのだろうか？ まず人工知能は人間を知る必要がある。（もちろん人間も人工知能を知る必要がある） 人間の何を知るのだろうか？ おそらく一番の相違点である感情ではないか。 とすれば、効率よく人工知能にとって望ましい形で学習するための材料というのは日記に違いない。それは特定個人の経年変化を持つ感情と行動の記録で
_ bitcoinのプロトコル覚え書き 昨日はブロックチェーン勉強会で、まずはbitcoinの仕組みの解説から。 教科書は山崎先生のBitcoinの技術 ノードは3つに分かれる。フルノード、その子分、マイナー。 フルノードはこれまでの全取引分のブロックを持つ。現在35GBくらい。起動時はそれを全部読みだして整合性をチェックする。子分はたかだか現在のブロックを持つ。マイナーは現在計算中のブロックを持てば良い（はず）。 取引の実行はあるノードが行う。このノードをAとすると、 取引は通常、AがBに金を払う。BがAに釣りを払う。Aがマイナーに0.001（1桁違うかも）払う。の3つ組。このとき、AはBに全持ち分を払い、実際の払い以外の釣りを受け取るものとする。すなわち、現在のAの有り高（なんで在で出てこない？）は、Aの最後の取引記録に残ることになる。Aはこれを自分が繋がっているすべてのピアへ送信する
_ Swiftデザインパターン 結論としてはモダンなデザインパターン本で、今となってはGoFより遥かに良いのだが、難点もある。 翔泳社の野村さんからSwiftデザインパターンをいただいたので、よしこれでSwiftを覚えようかと思った（のがクリスマス休暇だからもう2か月前になってしまった）が、読みはじめるとどうも勝手が微妙に違う。 翻訳本なのだが、筆者がデザインパターンマスター（普通にデザインパターンを適用して機能を実装にプログラミングできる人の意味。自称で十分なので、実はおれもそうなのだ）らしく、そういう人は実装用のプログラミング言語はそれほど問題とはしないので、Swiftが発表されてすぐに執筆出版したものらしくXcodeは6だしSwiftも1.xだ(コード標準も自分の律にしたがっているように思う)。 筆者は引退した元銀行のCTOだとか書いてあるが、考慮している現実的な問題を読む限り、パフ
_ APIデザインケーススタディ読了 RubyKaigiの前日に技評の方からダウンロード版のダウンロード権をいただいたので（ありがとうございます）、最初半分ほど一気読みした後しばらく寝かせて今読了した。 本書はRubyが持つAPIについて（田中さんが修正したり追加したりしたものを中心に、というか全部なのかな？）なぜそうしたのか、そのためにはどういう制約なり考慮があったのか、その結果どうだったのか、といった事例集だ。パターン集のようには抽象化されていなくて、題名通りケーススタディなので具体的だ。 おもしろかったし、教訓にあふれている。 以下の人は読む価値がとてもある。 ・Rubyプログラマ （ここで紹介されているAPIのうち、おそらく半分は使わないかも知れない。しかし田中さんのAPIデザインに対する影響力を考えれば、コアAPIや添付ライブラリのAPIを使う場合に、持っていると便利なお約束とい
_ 明治神宮不思議の森 タモリ倶楽部の録画を見ようとして、ふと妻が録画して残していたらしきNHKスペシャル明治神宮 不思議の森というのに目がいった。 で、見た。 おもしろかった。 知っているところもたくさんある。 作られたのは大正年間。当時は単なる荒地で、そこに植林して森にしたとか、そういったことだ。あと、立ち入り禁止になっている（参道以外は）とか。 が、大正時代の日本らしい壮大な計画があったことはまったく知らなかった。 森の設計をしたのは本多静六を中心としたプロジェクトチームで、何を考えたかというと、放置することで150年後に原生林を創り出すというものだ。 最初は針葉樹（荒地に強い松とか）を中心に、常緑広葉樹を混ぜておく。50年後には常緑広葉樹が増え、寿命が短い針葉樹が勢いを減らす。150年後には針葉樹はほぼ消えて常緑広葉樹の森になる。そのためにはどういう間隔でどう種類を植えるか計画する
_ なぜ機械学習といえばPythonなのか TDでmrknから機械学習の話を聞く会に参加。 家に帰ってからスルーしてはいかんなぁとWEB+DBを買うことになった。 WEB+DB PRESS Vol.89(佐藤 歩) いろいろ聞いて、どうやらPythonが機械学習のフルスタックを持っている点が大きいということがわかる。 ちょうど、最初にWebアプリケーションのフルスタックを用意したのがRailsだったというのにちょっと似ているのかなと思った。 特に、Array（忘れた。Sequenceかな？）のAPIによる統一が大きいとのこと。それによってCとのインターフェイスが標準化されてモジュールが集まりやすい。 RubyであればNArrayがその役回りを持つのかも知れないが、NArrayは標準ライブラリではないとか。 統計のあれこれが揃いまくっているのが大きくてRが使われているというような話もあった。
_ 人を信用する設計と信用しない設計の線引き Rubyは君を信用するが、Javaは君を信用しない。 それは設計ポリシーで、それ自体は悪いことではない。 どう信用していないかと言えば、まず最初に上げられるのは、無名inner classのメソッド内で参照する外側のローカル変数はfinalとして再代入を許さないことだ。 次が、ラムダ式用に用意されているjava.util.functionの使いにくさ=throws Exceptionが無い定義だ。 これらは、保存されて処理された場合を考慮すれば当然とも言える。 class Foo { Consumer<int> callback; public void addConsumer(Consumer<int> cb) { callback = cb; } private foofoofoo() { callback.accept(bar); } と
_ 大江戸Ruby会議05の続き たださんの「大江戸Ruby会議05」へ行ってきたを読んで、そういえば、懇親会の前あたりに、「個人的には興味の移り変わりを俯瞰して「ああ、やっぱりetoさんはアーティストなんだなぁ」としみじみ思ったり」な感想を聞いて（もっとなんというか、軽やかに花から花へ飛び回るような印象の言葉で、おそらくｔDiaryが15年（というようなことをおれが言ったからかそれとも逆に受けておれが行ったのか忘れた）というようなプロダクト指向（まつもとさんのRubyはそろそろ18歳だか成人だかとかと比較しても良いかな）との違い）、まあそうかなと思いながらも、何かひっかかりを覚えたのだが、ちょっと思い出した。 ひっかかりは、実は興味はそれほど移り変わっていないのではなかろうかということにあった。 ・（名前忘れた）、多分、tracerouteしながら、Webページのリンクを世界地図上で可視
_ 大江戸Ruby会議 殺されるかも知れないとなれば、人は3階から飛び降りることもできる。しかも踵の骨にヒビが入るくらいで済む。しかしもし保険に入っていなければ600万円くらいの治療費を要求される（NYでは）。 Perlは偉大 正しい実装よりも速度が重要（なこともある） 秘密キーを自分で持つのはやめれ akrさんのライブラリ設計読本が技評から出るらしい。でも題は「ライブラリを支える技術」では無い。 RubyはNilクラスがあり、かつオープンクラスなので次のようなこともできる。 class NilClass def method_missing(name, *args) nil end end しかし、これをやるとディスられる。 無駄に顔文字を使う変な人というキャラ設定でTwitする（左手で書くと謎の筆跡の変な人になれるというデュマの知恵みたいだ）。 メディアが百花斉放すれば高品質のコンテン
_ ここは退屈迎えに来てを読んだ（感嘆） 数年前に話題になっていた、ここは退屈迎えに来てがアマゾンKindleショップでえらく安く売られていたので、たまには最近の日本の小説でも読んでみようかと（藤井大洋とかは読んでいるから、たまにはというのとはちょっと違うかな。ノンジャンル小説でもというか）買って読んだら、えらくおもしろかった。 正確にはおもしろかったというのとは違うが、信じられないほどまともな文学作品で、いろいろ感じるところ多数。 文学とは何だろうか？ おれは次の2点を満たすことが条件だと考える。 ・相対的な観点から世界を構築し、それがまさに現実の世界の写像であること ・その世界を読者が自覚し、現実の世界に対する複眼的な視野が一瞬であろうとも提供されること たとえばソフォクレスやエウリピデスのような正統的なギリシャ悲劇を考えてみると、そこに描かれるのは主に、神が定めた運命に対して立ち向か
_ C#のGC.KeepAliveの謎 ちょっとSystem.Threading.Timerを使っていろいろ実験しているのだが解せない(追記：猪俣さんに、お前のドキュメントの誤読と指摘されたので、解せなくなくなった)。 以下は期待通りに3秒後にHelloが表示される。変数tの参照箇所はGC.Collectをまたいでいるから、t（その実体はTimerのインスタンス）が保持されるのは当然だ。 using System; using System.Threading; class TimerTest { static void Main() { var t = new Timer(state => Console.WriteLine("Hello!"), null, 3000, Timeout.Infinite); GC.Collect(); Console.Read(); t.Dispose(
_ メタプログラミングRuby 第2版 オライリーからメタプログラミングRuby 第2版をいただいた。どうもありがとうございます。 本書の初版はアスキーから出ていたが、ドワンゴへの移動やらなにやらの前の微妙な時期に第2版が出たのでオライリーに翻訳権が移動したらしい。出版社は変わったが、訳者は同じく角さん（というかkdmsnr）。 ざっと見たが、初版とえらく雰囲気が異なる。 章立てはほぼ同じなのだが、初版の特徴だった、「あなた」とビル（先輩というかメンターというか）が、課題に出会い、メタプログラミングでうまく処理するというユースケースドリブンな筋立てというか、仕事ハッキングライフスケッチみたいな雰囲気は薄まっているように思う。どうも物理的に行間が詰まっているせいで、読み物っぽさが薄まったように感じるみたいだ。 その分、よりプログラミングの本らしくなっている（行間が詰まった分だけ本の厚みも減っ
_ Javaにおけるインターフェイスの爆発 仕事環境でJDK1.8を解禁させたので、いろいろ試しているうちにとんでもないことに気付いた。簡単にインターフェイスが爆発してしまうのだ(あまりうまい表現ではないなぁ。ビッグバンが起きるという雰囲気を出したいのだが)。 ようするに、これまで糞面倒だったコールバックが異様に簡単に書けるようになったので、呼び出し側が簡単に利用できる以上は呼ばれる側も情け容赦なくコールバック関数を取るAPIを作るわけだが、異様に簡単なのはラムダ式を記述できるからだ。ということは、関数型インターフェイスをばかすか定義することになる。 そんなものは1メソッドあたりで定義すれば良いし、呼び出し側はどうせ型宣言とかしないのだから、内部インターフェイスで良いだろうと考える。すると1メソッド平均1.5インターフェイス、1クラスあたり5publicメソッドとすると、1クラスあたり8イ
次のページ
このページを最初にブックマークしてみませんか？
『Chacun fait fait fait, Ce qui lui plaît plaît plaît』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
