月別: 2015年12月

逝く年、くる年

ラビットハウスでのおしごと

  • 前半はジャバジャバしてた
  • 半ばすぎからクライアントサイド開発やってた
  • Swiftに文句言いながら必死に覚えてなんとか書いた

2016年

  • UIまわりと並行並列処理まわりのデザインパターンを覚えたい
  • ScalaかJava書きたい

その他

  • 運動する
  • 今年高飛びできなかったので、来年1ヶ月くらい放浪してくる
  • ラビットハウスを建てる

モデルビューコントローラー

注: PoEAA, 14-1: Model-View-Controller をまとただけの記事です

UIの相互作用を3つの明確な役割に分割するパターンを「モデルビューコントローラ」とよぶ。

mvc

ViewとControllerは互いに依存してよい。ViewとControllerはそれぞれ、Modelに依存してよい。

パターンの仕組み

 モデルはUIに関わらないドメインについてのデータやふるまいが表現されたオブジェクト。ビューはUIの中でモデルを表現する。ビューは情報の表示だけを責務として負う。コントローラは、ユーザーからの入力を受け取り、モデルを操作して、ビューを適切に更新する。このようにUIはビューとコントローラの協調によって構成される。

プレゼンテーションとモデルの分離

 根本的にプレゼンテーションとモデルは異なる関心事を持っている。ビューはどのように良いUIを提供するかということに興味があり、モデルはどんなロジックでデータを取り扱おうかということに関心がある。したがって分離を行い、各関心事に応じて構造化するために分離を行う。

 非ビジュアルなオブジェクトは、ビジュアルなオブジェクトよりテストがしやすい。当たり前のことではあるが、プレゼンテーションとモデルを分離することにより、ドメインロジックのテストは容易になる。

 プレゼンテーションはモデルに依存するが、モデルはプレゼンテーションに依存しないようにする。こうすることによりモデルを構成するときに、どんなプレゼンテーションから使われるかということを全く意識しなくてすむようになる。また、これによりモデルを利用して新たなプレゼンテーションを追加することが容易にもなる。

複数のウィンドウを持ったクライアントにおける問題

 複数のウィンドウを持つリッチクライアントでは、あるモデルを参照する複数のプレゼンテーションが同時に表示される可能性がある。その際、ユーザーが1つのプレゼンテーションを更新したら、その変更は伝播されなければならない。モデルがプレゼンテーションに依存を作らずにこのようなことを実現するためには、オブザーバーパターンの実装が必要になる。プレゼンテーションはモデルのオブザーバーとして動作させ、モデルが変化するごとにイベントが発生して、情報が更新されるされる仕組みを実現する必要がある。

ビューとコントローラの分離

 こちらは、プレゼンテーションとモデルの分離に比べると重要度は下がる。例えば、編集可能な振る舞いと編集不可能な振る舞いを同時にサポートをしたいときに、ビューとコントローラを分離したいといったモチベーションが生じる。1つのビューに対して、2つのコントローラを作ることにより対応できるが、通常はそのような分離は行われていない。

 プラットフォームによってはUIにおける入力と出力はしばしば不可分であり、GUIフレームワークではビューとコントローラを組み合わせていることが多い。Webインターフェースではコントローラとビューの分離が行われることが多い。

パターンを用いるタイミング

 モデルビューコントローラは、プレゼンテーションとモデルおよび、ビューとコントローラの分離に特徴がある。前者については非常に重要で、ほとんどの場合、分離をすべきである。後者についてはわりあい重要ではなく、必要なときにだけ分離をすることを推奨する。ネイティブクライアントにおいて、分離することはほとんどないが、ウェブフロントエンドにおいて、ビューとコントローラを分離することは珍しくない。

感想

モデルビューコントローラについては POSA を読まないとダメそうだ。正直PoEAAの説明、わりと雑では?と思ってしまった。あと このあたり を読んでおきたい。

Web Presentationのアーキテクチャ

注: PoEAA, Chapter 4: Web Presentation をまとただけの記事です

 ウェブブラウザベースのユーザーインターフェースには、特別なクライアントソフトウェアをインストールしなくてよい、UIに対して共通のアプローチをすることができる、世界中からのアクセスができるなどのメリットがあります。またウェブアプリケーションは、多くの環境でビルドすることが可能であるということは大きな利点です。

 ウェブサーバーアプリケーションは通常、各URLに対してどのプログラムが対応して処理を行うかを記述した設定ファイルを持ちます。これをもとにウェブサーバーはURLを解釈して、それに紐付いたプログラムに制御を渡します。そしてそのプログラムは動的に結果を生成し、レスポンスを返すなどということを行います。このようなウェブサーバーアプリケーションの構造化には、スクリプトとしての構造化とサーバーページとしての構造化という方法があります。

スクリプト形式

 スクリプト形式のプログラムは、HTTP呼び出しに対して対応する関数やメソッドを呼び出して対応するものになります。CGIスクリプトやJavaサーブレットといったものはスクリプト形式に分類されます。スクリプトはさらに細かく分割することができたり、他のサービスを操作することができます。レスポンスはストリームへの書き込みを行うことで実現します。

サーバーページ形式

 スクリプト形式におけるHTTPレスポンスのストリームへの書き込みは非プログラマにとっては困難であり、プログラマであっても煩わしい作業となります。これを解決する方法として、サーバーページ形式というものがあります。これはHTML形式で書かれたレスポンスページ内に実行可能なスクリプトを記述し、ある時点で実行処理を行うというものになります。PHPやASP、JSPなどがサーバーページ形式に分類されます。そもそもASPは、Active Server Pagesの頭文字、JSPは、JavaServer Pagesの頭文字から来ています。スクリプト形式はリクエストの解釈が簡単に行える点で優れています。また、サーバーページ形式はレスポンスのフォーマットを定める方法として優れています。

レイヤ化アーキテクチャ

注: Patterns of Enterprise Application Architecture, Chapter 1 Layering をまとただけの記事です

 レイヤ化は、複雑なソフトウェアのシステムを分割するために使用される技法です。コンピュータの構造やネットワークなどソフトウェア以外の設計でも使われています。各レイヤはその下のレイヤに依存します。レイヤ3はレイヤ2を利用して、レイヤ2はレイヤ1を利用します。レイヤ化アーキテクチャにおいて最も難しいのは、必要なレイヤと各レイヤが行うべき内容を決定することです。

レイヤ化のメリット

  • 他のレイヤを気にせず、1つのレイヤを全体として考えることができる
  • 同じインターフェースを持つだいたい実装でレイヤを置き換えることができる
  • レイヤ間の依存を最小限にできる
  • レイヤは標準化に適している
  • レイヤを構築することにより、多くの高水準サービスがそのレイヤを使用できるようになる

レイヤ化のデメリット

  • 物事をカプセル化してしまうため、連鎖的な変更が起こる場合がある
  • パフォーマンスを損ねる場合がある

 UI上で表示すべきフィールドの追加が、前者の具体的な例になります。追加されるフィールドに対応するものがデータベース上に存在する必要があります。このためUIからデータベースまでのすべてのレイヤにそのフィールドを追加する必要が生じます。後者についてはパフォーマンス損失以上にトランザクションの制御などの最適化によって得られる恩恵が多いケースもあるので検討が必要です。

レイヤ化の発展

 90年代に登場したクライアント/サーバシステムは2レイヤのシステムでした。クライアントはUIとアプリケーションコードを保持して、サーバーは通常のRDBという構成でした。アプリケーションがRDBの内容の表示と更新といった単純なものであれば適切に動作しましたが、妥当性の検証など複雑なドメインロジックを伴い始めると、たちまち重複コードが増えたり、コードの扱いが難しくなったりする局面がでてきました。そのころオブジェクト指向も注目を集めていて、コミュニティではプレゼンテーション、ドメインロジック、データソースの3レイヤにすることにより、ドメインロジックに関する問題を解決しました。最終的にはWebやJavaの登場により、こうしたやり方が受け入れられ、定着することとなりました。

3つのレイヤ

プレゼンテーションレイヤ

 ユーザとソフトウェアの相互作用を扱うのがこのレイヤの役割になります。ユーザーに情報を表示したり、ユーザーからのコマンドをドメインやデータソースでの動作に変換したりするようなコードがここに含まれます。

ドメインレイヤ

 システムそのものであるロジックを置くレイヤです。ビジネスロジックとも呼ばれます。入力データや格納データに基づく計算や、入力データの妥当性検証、また状況に応じたデータソースの選択などがこのレイヤに含まれます。

データソースレイヤ

 他のシステムとの通信を行い、アプリケーションのためにタスクを実行します。

レイヤ化アーキテクチャとヘキサゴナルアーキテクチャ

 ヘキサゴナルアーキテクチャは、外部システムへのインターフェースで囲まれた核としてシステムを視覚化したものです。外部にあるものはすべて外側のインターフェースとします。よって、ヘキサゴナルアーキテクチャは他への提供するサービスと他のサービスを利用することを区別しない、対称的な構造を持っています。対して、レイヤ化アーキテクチャは、他へのサービスとして提供するインターフェースと、他のサービスを利用することを区別する、非対称的なスキーマになっています。そして、この部分がプレゼンテーションレイヤとデータソースレイヤの違いとなっています。

レイヤリングの方法

 システムの規模によって異なります。単純なものであれば、各レイヤのふるまいをサブルーチンとしてあげるだけで大乗ウブです。より複雑なときにはクラスに分割を行い、さらに複雑な場合には幾つかのパッケージにクラスを分割してあげるということができます。状況によって一番適切な分割をするのが望ましいですが、最低でもサブルーチンレベルでの分割を行う必要はありそうです。

レイヤ間の依存関係

 ドメインとデータソースはプレゼンテーションに依存しないようにします。ドメインとデータソースの関係は複雑なため、データソースのアーキテクチャに応じて考えていく必要がありそうです。

レイヤの実行

 PoEAAの内容のかなりの部分は、論理的なレイヤについて解説したものになっています。システムを分割して、その境界部の結合を減らすことについての説明が書かれています。レイヤの分割は1台の物理マシンで実行していたとしても役に立ちます。しかし実行場所が異なることによって違いがもたらされることもあります。

 クライアント/サーバーなアプリケーションを例にとれば、サーバーですべてを実行すると、アプリケーションの更新は容易になります。一方クライアント側での実行はレスポンスや切断時の操作を考えると優れています。

ごちうさが何期まで続くか、Swiftコンパイラに聞いてみた

まずは、高尚なクラスを作成します

続いて、次のようなテストコードを書きます。

普通にテストが通るかと思います。あとはひたすらテストコードを増やしていくだけです。

ご注文はうさぎですか? アニメーション第3370期制作決定

手元の環境(Xcode 7.2)だと、ごちうさの第3370期の制作までが確定しました。オープンソース化されたSwiftの今後の開発次第ではさらなる続編の制作が決まるかもしれないので、期待感が湧いてきますね!

ちなみに3371期目のテストを回そうとするとこうなります

来週で2期の放送が終わってしまいますが、続編が3370期も続くことがわかってるなら、楽しく暮らせそうですね。

GitHub

ソースコードを公開しているのでお気軽におためしください
https://github.com/53ningen/usagi_anime

編入学のススメ

この投稿は 退学 Advent Calendar 2015 の20日目の記事です。

 国公立大学の多くには編入学という制度があるので、国公立大学を目指していたが私立大学にしか入れなかった方や、私立大学に行ったが学費が厳しくて #okane_nai と思っている方に向けて、国公立大学理系学部三年次編入学制度についてのご紹介をします(自分はその両方に該当する)。

三年次編入制度とは?

 文字通り大学の学部三年次に入ることのできる制度です。高専などの学生は卒業時には大学2年生相当の年齢になっているため、そのまま高専を卒業後、三年次に編入できるこの制度を使うことが多いみたいです。ただ、受験資格を満たしていれば高専生だろうと大学生だろうと受験可能です。

 特に、四年制大学からの編入学条件は、だいたい大学に2年以上在籍し、62~64単位を取得していることとなっている場合が多かったです(2011年当時の情報)。また工学系の学部は同系統の学部からの編入生しか受け入れていないケースが多かったです。理学系に関してはあまり縛りをみたことはないです。また、一般入試はセンター試験を受けて前期後期2回しかチャンスがありませんが、入試日程が被っていない限り、編入試験は何回でも受けられます。

入試の内容

 主に大学1〜2年レベルの数学、物理学の内容と英語の試験、口頭試問があるケースが多いです。一般入試の場合、たくさんの科目を勉強してセンター試験で点数を稼がなければ厳しいのですが、編入試験は専門科目を頑張れば良いのでお得感があります。

 数学は、主に線形代数と微積、複素解析を押さえておけばOK。物理は、力学と電磁気学、熱力学、電気回路あたりがよく出る模様。英語はふつうの大学入試レベルなので、まあ普通に頑張れとしか言いようがない。

単位認定の話

 あくまで私個人のケースですが、入学後、放送大学で取った線形代数と微分積分学の単位が認定されました。大学の教室に通わずに家で寝ながら勉強してれば大抵単位とれるような内容なので怠惰な方にオススメです。わざわざ出席数を稼ぐために教室行ったり、雑な出題のレポート解いたりするの面倒くさいので、これは非常に良かったです。

 結論から言うと持ち込んだ69単位のうち、53単位が編入学後の大学で単位認定されました。これで国公立大学に入って学費が安くなるならまあ良いかなぁという気がします。あと体育はちゃんと単位とっといたほうがいい(戒め)。

編入学はオススメできるのか

 わりと勉強大変だった。本気でやる覚悟がない人にはオススメできない。でも国立理系だと学費が半分くらいになって非常に良い。私立理系の学費高すぎる。奨学金もただの借金なんですよね…という。

 編入学自体は、いろいろな選択肢のうちの一つとして、もっと知ってもらえると良いかなぁと思います。自分の場合はわりと学費面で厳しさを感じていたのですが、そうでなくても色々な事情で厳しさを感じている人がもしいたら、留年したり、退学したり、休学したり、就職したり、編入学したりするのは選択肢として普通にあるので、最後は自分の意思次第でまあなんとかしていきましょうとかそういう内容の記事でした。

 まあ学校なんて行かなくても死にはしないので、そういう気持ちは大事だと思います。

退学 Advent Calendar 2015。明日は @kwappa さんの記事です。楽しみにしています。

ひと目で、尋常でない牛めしだと見抜いたよ

この投稿は 松屋 Advent Calendar 2015 の4日目の記事です。

 みなさんは「ご注文はうさぎですか?」という作品をご存知ですか? もし知らない方がいらっしゃいましたら、Googleで「1」で検索すると情報が出てくると思いますのでお試しください。さて、この素晴らしい作品を楽しむにあたってお腹が空いた状態だと困ります。

 そこでオススメしたいのが松屋の牛めしです。大抵のイベント会場の近くに松屋は佇んでいるので、のれんをそっと潜りましょう。たとえば、ご注文はうさぎですか?? 第1羽先行上映会前の様子がこちらになります。

 また、CHINO HAPPY BIRTHDAY イベント前の様子がこちらです。  

 牛めしを食べたおかげで、イベントを楽しめる体力をつけることができました。今日も松屋に感謝。

CHINO HAPPY BIRTHDAY イベントについて

 去る12月4 日は、香風智乃さんのお誕生日でした。中野サンプラザにて、日頃の感謝を伝えるべく大規模な誕生日会が執り行われました。イベントにはまずタカヒロ役の速水 奨さんが登場しました。大誕生日会になってしまい少し緊張してしまうかもしれない水瀬いのりさんを気遣ってか、まずはタカヒロさんとのコールアンドレスポンスで場を温める配慮です。わたしたちも日頃、訓練を重ねているとはいえ、やはり万全の体制で水瀬いのりさんをお迎えしたいので、全力で準備体操を行いました。

 そして、いよいよ待ちに待った水瀬いのりさんの登場です。大きな声援が飛び交う中「出かけましょうと答えましょう」からライブパートのスタートです。まるでCD音源を流しているかのような安定した音程・声量を保っていてさすがプロだなぁという感想を抱きました。でもちゃんとマイクから拾った声であるのは確かに確認できました。やはり水瀬いのりさんは天才なんだなぁということを確信しました。一方、客席の我々は、Cup of chinoが発売されてからまだ時間がそれほど経っていないということもあり、練度が低い状態だったのは次回に向けての課題となりそうでした。水瀬さんに喜んでもらえるように、我々も努力していきたいですね。

 続いて「未来パズル」「新作のしあわせはこちら!」。個人的には「新作のしあわせはこちら!」がとっても好きなので生歌が聴けて本当に嬉しかった。「Eを探す日常」のPandaBoYさんが作曲していて、今回もさすがの良曲です。特に、途中にSE的に入る「きらり〜ん☆」という部分はグッときます。

 このイベントで特徴的だったのが、中の人だけでなく香風智乃さん本人も登場していた点です。おそらくミラクルガールズフェスティバルに用いられていると思われるモデルを利用して、実際にステージ上に香風智乃さんが立っていました。それだけではなく、水瀬さんと一緒にデュエットを行ったりとかなり挑戦的な演出が行われていて、今後のイベントの新しい方向性を提示してくれるものだったのではないかなと感じています。

 ごちうさ声優は全員第一線で活躍されている方ばかりなので、イベントの開催がかなり厳しくなってきています。こういった、CD音源+モデルと中の人のデュエットという形は、中の人の負担を大きく減らしたり、間をつなぐことができて画期的な仕組みだなあと感じました。これを用いれば、各キャラクターやユニットごとの括りでちゃんとしたイベント開催が可能だと思います。

 課題としては、まだ動きの作り込みが甘い点があったり、ボイスのバリエーションが圧倒的に足りていなかったりといった点でしょうか。いずれにせよ今回の演出は大成功のレベルに達していたと思うので、今後のさらなるクオリティアップに期待したいです。

 次に「きらきらアラモード」「かえりみちスキップ」。手拍子のタイミングもっと合わせたかったですね。客席側の練度不足でした。そして、タカヒロさんが衣装チェンジをして「Daydream cafe Xmasver」をチノちゃんと熱唱。オケは1期Blu-ray6巻に収録されていた「タカヒロ&青山さん」のダブルはやみんバージョンの編曲でした。この編曲ものすごいアガる曲調で大好きで、まさか生歌を聞けるとは思いませんでした。この選曲にはさすがに鳥肌がたってしまいました。

ラテアート職人さんとPandaBoYさん

さて夜のラビットハウスパートでは、ごちうさ界隈でラテアートで有名な職人さんとPandaBoYさんが登場!こういう演出、個人的には結構好きなのですが、会場にいた方どうだったでしょうか?PandaBoYさん+タカヒロさんがバックでDJをやりつつ、ラテアートを完成させるというかなりアグレッシブなコーナーで、個人的にはタカヒロさんが困惑しながら頑張っている姿が面白かったです。

ティッピーからのお祝いのメッセージ

 チノちゃんの誕生日なので、我々からもお祝いのバースデーソングを贈りました。またティッピーからのお祝いのメッセージも届いており、清川さんの言葉が染みるなぁと思っていたら、まさかの清川さん本人が登場!!!!!これは本当にびっくりした。いつか清川さんがイベントに登場してくれれば良いなぁと思っていたのですが、まさか今回それが叶うとは…。清川さんから花束が水瀬さんに手渡されました。

 そして、これだけじゃない!りえしょんが駆けつけてくれた!!!最近りえしょんイベントに行けてなかったので、嬉しかった。あいかわらずでしたが、やっぱりイベントでりえしょんの姿をみるととても元気が出てくる。やっぱり村川梨衣さん大好きです。俳協のお二方の登場で盛り上がったところで、記念撮影。最高の思い出になりましたね…。

魔法少女チノ 降臨

 魔法少女コスチューム最高に似合っていた。アンゴラウサギの帽子も、ひと目で尋常でないもふもふだと見抜けるくらいちゃんと作ってありました。その衣装で例の曲を歌うのは反則ですね。本当にチケット代の何倍もの価値があるイベントでした。

 最後は「ときめきポポロン」。やっぱり盛り上がりますね!みんなで一緒に熱唱して良い締めくくりとなりました。終わりの挨拶で、水瀬さんがマイクを使わずに地声で中野サンプラザの広い会場に声を届けてくれたのが本当にうれしかった。

 こんな素晴らしいイベントを開催してくれて本当に感謝しかないです。チノちゃん、水瀬いのりさん本当にお誕生日おめでとうございます!お忙しいと思いますが、体調に気をつけて、これからもますます活躍してください!