SPAJAM2016とこれからの彼女の作り方

おばんです、最近白髪も増えて徹夜のできない体になってきたしょぼしょぼの田中です。

2016/4/16-4/17にSPAJAM2016というハッカソンの東京B予選に友人と参加してきました。
残念ながら受賞できませんでしたが、その時実装した設計と得た知見の共有とポエミーなこと書きます。(サーバーサイド担当が友人で、僕はフロントiOSだったので詳しくは語れませんが)

前提

ハッカソンのテーマが「不注意にそなえる」というテーマでした。
僕のチームは居眠り運転などの不注意から起こる交通事故 -> 突然の死など大きな問題ではなく、夜更かしや会議中トイレに行きたいなどの普段意識から外れがちな低レイヤーな不注意を防ぐという目標を持ちました。
夜更かしなどの低レイヤーの不注意にそなえることは心の余裕を持つことにつながり、結果として大きな不注意、危険度の高い高レイヤーな不注意も防ぐことができます。一石二鳥。

作ったもの

ということで作ったものが以下。





黄色が特に可愛い。うちのチームのデザイナー神。




メッセンジャーはオウム返しまでできた。




コビトさんがグーグルカレンダーから前後の予定を見て、予定にない低レイヤーな不注意をおしらせしてくれるリマインダー。アプリには実装されてないけれど、「トイレ行っといた方がいいよ！」とか注意を促してくれます。




リマインダーをこなしていくとアプリ上でポイントをもらえて、それでガチャを引くと新しい個性的なコビトさんがもらえるというもの。もらったコビトさんは設定するとbotに反映される。口調とか性格がそれぞれ違う。
キャラクターに小人さんを選んだのは、寝落ちして気付くとバグがいつの間にか直っているという奇跡が小人さんの仕業だというエンジニア界隈の都市伝説から。

アーキテクチャ

これで利用したアーキテクチャが以下の図になります。



仕組みとしては難しくありません。

FB Messengerアプリ, Lineアプリを使ってbotと会話します。
そのbotはサーバー側で管理していて、メッセージのやりとりを見ています。
メッセージのやりとりが行われたら、その情報を拾って自分のアプリとデータのやりとりをします。
アプリ側からはコンソールのような形でキャラクターを変えるとかでbotの設定を変えてやるもよし、ゲーム要素を取り入れてなんらかのパラメータをやりとりするもよし。
今回はプラスアルファとしてGoogle Calendarの情報も同じように自分のアプリとサーバー側で共通のカレンダーを参照するようにして一つのデータベースのような形で扱いました。
それによって、botが自分の予定を知っていて注意喚起してくれるという状況を作り出しました。

使っているのが普段使っているMessengerやLineなところにリアリティが生まれました。

彼女が欲しい

この例を使うとなんと彼女が作れます。


（まだ実際には作ってないけど）

やはりFacebook MessengerやLineなどのリアルと密接したメッセンジャーの結果がアプリに反映されるリアル感が良いですし、そこにゲーミフィケーションの要素を自作アプリにつけることも可能です。
もうギャルゲですね。

日常的な会話をしたいじゃないですか。
予定を共有して把握していてほしいじゃないですか。
そこからの会話の発展とか、自分のことを知ってほしいじゃないですか。

このアーキテクチャなら彼女が出来ます。

展望

以下が実現できるとよりアツいと思う
・蓄積したデータによるキャラの学習
・蓄積したデータによるユーザーとの関係性の変化
・「「自発的に」」情報の取得、ニュースの情報を拾ったりして日常会話へ反映
・プラットフォーム化（Bot ShopやSDK）

ツンデレライブラリ、ヤンデレライブラリ、ケモミミライブラリ、ドジっ子ライブラリなどアツくないですか。
耳があることによる身体的な常識から生じる日常会話の変化や、ドジなので約束したことをGoogle Calendarに入れ忘れるとか。
あ、ヤンデレだったらカレンダーから誰と何してるかの情報が筒抜けですね。とかとか...。

さいごに

途中からbotとしてなら普通のこととか色々ノイズが入っちゃってましたが、いいんです、真姫ちゃんが可愛いです。

技術的には、Line botはLine側とのSSL関係で1〜3日かかってしまうケースもあるようなので注意が必要です。
Facebook Messenger botは初回の設定項目が多くて大変なようです。

なお、現実彼女を作ることに関してはそもそも女性の分母が少ないエンジニア界隈をターゲットにするのは間違っていると友人に指摘されました。料理教室通うとかデザイナーのいる勉強会に行くとかその他の施策をオススメされました。

東京来て一週間

おばんです、田中です。
入社から1週間が経ちました。

ゆっくりではありますが、会社の人の顔と名前を覚え始めてきました。
仕事も順調なように感じてとても良いです。

まだ聞き慣れない用語が飛び交っているように感じはしますが、コーディングやgitの運用方法などこれまでやってきたことは軽くすり合わせをした程度の段階ではありますが、なんとかやれそうな気がしています。

これまで一人で取り掛かる案件・開発がほとんどだったりしたので複数人が同じ場所で仕事をするということにとてつもない安心感と安定感があります。
一人だとあれもこれも、とタスクの分野のスイッチの切り替えを多くしなくてはいけなかったのですが、それがいかに脳内のメモリとCPUの処理に負荷をかけてたかがわかります。

プログラミング、開発の手法・手順、お客さんとのやり取りの仕方などプロが揃ってる中で安定したスキルの吸収ができるのがすごく贅沢。


最近は個人でもまた勉強会の開催を企んでいたり、技術ではSwiftでこれまでと違うアプローチでコードを書いてみたり、Unityに触れてみたり、AWSにも手をつけようかとしていたりするような感じです。
仕事を始めると時間が無いと周りの人に言われていたのは本当で、なかなかブログでまとめられる単位までもっていくのに時間と体力のバランスをとるのが難しくも感じます。ブログの更新頻度も加速せにゃあならん。
無理せず、だんだんと慣れながらやっていこう〜。


料理も徐々に始める感じで。
調味料と作業スペースの机が無いのがとても難しい。
実家最強説。実家最強といえば、あとは湯船に浸かりたい。


田中家式ではないカレー


あと方々から、amazonのwishlistで救援物資をいろいろと頂いています！
wishlistすごい便利〜。
みなさんありがとうございます！

try! Swiftに参加してきました！感想編

おばんです、田中です。
3月2日から4日の三日間にかけてtry! Swiftという、プログラミング言語のSwiftの世界的カンファレンスに参加してきました！
そのレポートです！

今回はgihyo.jpさんの方で一日目のオフィシャルレポーターもさせていただきましたので、後ほど記事はアップされると思います！ありがとうございます！

参加のきっかけ

父から報告されたRealmの岸川さんのTweetから知る。

try! Swiftカンファレンスの告知を開始しました。今回は特に多数の海外の著名なエンジニアの方がスピーカーとしていらっしゃいます。
もちろん日本の方の発表もあります。同時通訳も準備する予定ですので皆さん参加してくださいませ。 https://t.co/iYx3qZYVqa

— kishikawa katsumi (@k_katsumi) 2015年11月18日

即断即決、これ大事。

try! Swiftに向けて予習した

参加者と値段を見る限り圧倒的に濃い内容であることは明白でした。
今の自分のSwift力ではとても技術を吸収しきれないと......。
そこで予習することを決めて、同じく参加予定だった@totottiさんと予習として勉強会を開催しました。



Sendai.swift第0回 Protocol-Oriented Programming in Swift
Sendai.swift第1回 Reactive Programming in Swift
Reactiveは哲学だ！ with Swift

内容はProtocol-Oriented ProgrammingとReactiveについてだったのですが、参加してみて予想通り、予習によって理解できる範囲が広がってとてもよかったです。

@totottiさんとは復習会もやろうと話をしているので、仙台開催ですが興味あるか方は是非参加してください！

try! Swiftの様子

参加費の3万円の中に朝食と昼食、そして最終日は懇親会が開催されたのですが、これも参加無料だったので含まれてるのかと。
美味しかった！




電源スポットとWi-fiもあってかなりの充実っぷりです。
電源は人気すぎてブレーカー落ちたりしてました。

挙手

僕はイベントに参加した時は極力挙手して質問するようにと心がけています。

・登壇者の方・参加者の方と話すきっかけを持てる
・会場が盛り上がる
・自分の技術的な疑問の解消

の三つに役立つからと思っています。

あとTwitterも盛り上がったのでよかった。
話しかけてくれる方がいたりして実際効果がありました。楽しかった。
「あのダンボールの人ね」って後で言ってもらって嬉しかった。w

それと挙手して質問した時の"That's a good question."と質問内容のリピートをしてくれることの安心感は半端なかった。

積極的Q&A

あとはセッション後のQ&Aも活用させていただきました。
一日目のオフィシャルレポーターとして、聞き逃した部分や疑問点の解消に役立ちました。

try! Englishで技術的質問

try!なのでエラーで落ちるかと思いきや、相手の海外の方が意図を汲み取ってくれて助かりました、ありがとう！
二日目最後にSwiftらしいTableViewの話をしてくれたChrisさんにセッションについて質問した内容でした。


僕「How do you use tableview on storyboard?
宣言ってどう言うんだっけ...、宣言時にジェネリクスだと使えないやんって聞きたい...（ぼそっ
You can't use tableview on storyboard yesterday's your session approach.」

Chrisさん「Ok, give me a paper and a pen.」


みたいなやり取りをしてこんな図を書いてくれました。（写真がアレだけど）



意図を組んでくれて、コードと図で説明してくれたのでわかりました！
ソースコードは共通言語だよやっぱり！！

オフィシャルレポーターになったこと

またまた岸川さんのTweet。

try! Swiftのレポート記事をgihyo.jpに寄稿してくださる方を探しています。「PyCon JP 2014参加レポート」 https://t.co/KX1PNv0wvS のような形で1日のまとめを1つの記事で３つ、と考えています。原稿料はお支払いいたします。

— kishikawa katsumi (@k_katsumi) 2016年2月17日

このTweetを見て自分がオフィシャルとして務まるだろうかと、不安もありましたが、今後ともレポーターの立ち位置や、こういうイベントで役に立てるようにと思って頑張ってみました。

フラグ立てた

来年は登壇者として参加できたらいいな...！と思ったので予行演習とフラグ立てしました。
＜＞でジェネリクスを説明するイメージ

次回開催とかあれば登壇させてほしいｱｯﾋﾟﾙ#tryswiftconf pic.twitter.com/V6RgLNBgpm

— ダンボー田中@怒りのﾃﾞｽ･ﾛｰﾄﾞ (@ktanaka117) 2016年3月4日

頑張って勉強します！勉強しますから！

いろんな人と話せた

ネット上で知っていたあの人やこの人と会って話ができたのがよかった！
自分にとってはそんな人たちが目標なので。

Swiftのアツさ、OSSのアツさ、エンジニア道のアツさ

JesseさんのオープンソースのSwiftに貢献することについてのお話。
自分自身正直コンパイラや技術的なところへの貢献は難しいと感じています。しかし貢献できるポイントはそこに限らず、今後のSwiftに実装してほしいことの意見を出すことや、Typoの修正など、貢献できるポイントはいくつもあります。
プログラミング経験の差に関係なく意見を出して議論することに意味があって、初心者だとしてもその意見は初心者にとってSwiftが使いやすい言語になっていく糧となるということです。
やさしさと思いやり、そして助けを求めていくことでSwiftへのContributeをしていってください。仮にRejectされたからといって、たまたまそのタイミングでは利害が合わなかっただけで、そんなに気にすることはないと。

Swiftは一プログラミング言語に限らず、コミュニティである。各々が活発にContributeを続けていくことで、Swiftの利用範囲は広がっていき、みんなにとって利益のある素晴らしいエコシステムが出来上がっていくというお話でした。

日々のエンジニアとしての生活を勇気付けられた、とても感動したセッションでした。
ということでSwiftのメーリングリストに登録してもメールボックスが蹂躙されなくて済むというHirundoを落としてみました。
Contributeしていこう。

かっこよかったこと

「ドーン！！！」が面白すぎたのでアプリ名が聞きたくて、Chrisさんに質問しました。
そうしたらこんな返答でした。

Q.「ドーン！！」とか「ポケモーン！」とかはなにかアプリを使ってるんですか？
A.Timにならって書いた\ドーン！！/#tryswiftconf

— ダンボー田中@怒りのﾃﾞｽ･ﾛｰﾄﾞ (@ktanaka117) 2016年3月3日

かっこよすぎ。

みんな楽しそうだった

今はSwiftといえばiOSやMacOSのアプリの開発に使われている言語ですが、オープンソース化によってサーバーサイドや、リナックス上で動くことで活躍の幅を広げているように感じます。
また、ソフト開発やチーム開発やテストなど、単純に言語としてどうこうというトピック以外も取り上げられていました。
人それぞれ抱える課題は違えど、技術・開発共々幅広くカバーした構成になっていてみんな楽しめる内容だったので素晴らしいと感じました。

イベント自体の振り返り

・シングルトラックがよかった！マルチトラックだと被りが悲しいので。
・Q&Aセッションの被りがつらかったけれど、仕方ないかとも思った。

まとめ

try! Swift 2017がもし本当に開催されるなら、また参加したいです。
Awayokuba、登壇者として参加したいです。
本当に楽しく充実した三日間でした。

コンテンツとコンテキストと価値

rebuild.fmの#129でコンテンツのコンテキストの話があった。

コンテンツをシェアする人によってそのコンテンツのコンテキストが変わるということがある。
誰がシェアするかによってそのコンテンツの良し悪しが受け手にとって左右することがあるという話。

具体的な例として、「明日から使える！たった7つのIT現場改善法」という記事があったとする。
この記事に対して大学を出たばかりで現場経験値の低い私、田中が「良い」と言ってシェアするのと、
業界歴10年以上のベテランエンジニアが「良い」と言ってシェアするのでは意味合いが変わるというような話。
これはコンテンツがシェアされる時に新たな付加価値が加わって、形が変わった新しいコンテンツになっているという見方ができるかもしれない。

コンテンツは形を変える

人

映画を見るとき「誰と」観るか
ご飯を食べるとき「誰と」食べるか

「誰と」という、人が生み出すコンテキストはその人のキャラクターによるところが大きい。
コンテンツや何らかの経験自体の価値ももちろん重要だが、キャラクターが生み出すコンテキストに価値があるんじゃないか？と考えた。

生み出されたコンテキストは付加価値で、元のコンテンツに上乗せされて新しいコンテンツになる。

経験値

人の経験という話だと、最近こんな記事を読んだ。
社員には仕事ばかりさせないで旅行させたりしようという経営方針の会社の話。
「長時間働くな、良く眠れ、そして旅に出よ」お金を出して社員に旅行させる理由、CEOが明かす

経験値が高く、良い視点をもった人には能力があり、いろいろなコンテキストを生み出す価値がある。
ともすればこの経営方針は「価値を生み出すことのできる価値のある人間を作り出そう」ということか。

単純に元のコンテンツの価値の高さというのも重要な要素だし、それが価値にもなるけれど、そのコンテンツやあらゆる事象に対してコンテキストを上乗せさせることのできる人にこそより大きな価値があるように考えた。
考えてみればテレビに出てくるようなタレントがCMに出たり何か言ったりするのも同じことですね。

結

人がシェアしたコンテンツは形を変えて新たなコンテンツになりうる。
その人の経験に基づいて形成されたキャラクターがどうあるかというのはとても重要なポイントだという話でした。



以下はrebuild.fmネタだけれど、
rebuildで話題にされるSHIROBAKO、Fateはただのアニメとはまた違うコンテキストを持ったコンテンツになっている。
「naoya itoの絶賛する、マネジメントについて考えさせられるアニメ、Fate」となる。
聖杯問答はアツい。


ろくろ王イスカンダル

これはもともとtech系のネタを求めた人がアニメに興味を持つ副作用もあったりするかも。
元々アニメ好きというわけではない人も「最近のアニメってこんな話があるのか、こう見ると面白いかも」っていう「アニメの見方」が伝わる。
アニメエバンジェリスト。

P.S.

エンジニアはキャラクターに関して結構敏感だと思う。
「Webに強いAさん」「SwiftではピカイチのBさん」「テストにうるさいTさん」とか。
個人でなく会社に対しても、「AWSに強いC社」「ブログ書いてばっかりのM社」。
どこの分野で光っている人・会社なのかとか。

自分がどんな仕事がしたいかとか、この現場ではどういう振る舞いをすべきかとか、そういうことをよく考える傾向にあるんじゃないかなぁと思った。

人の印象に残る強いキャラクター性をもつことが今後を生き残る鍵？
なるしかないか、Swift芸人に...。


先述したように立場はコンテキスト・アウトプットを変える。

• 自分が現在どの立ち位置にいるのか
• 今後どの立ち位置にいるべきか
• どんなアウトプットがしていきたいか

っていうのは常々考え続けにゃならんなぁと思ったなぁ。

エンジニアライフの送り方、楽しみ方

一介の技術者だった彼が、どうやって仕事を楽しいことにしたか。
これを読んで思った事。

表を通常業務、
裏を通常業務外での活動や勉強と考える。
（自分の場合はIT勉強会に出て懇親会で酒を飲むこと。技術を得つつ、コミュニケーション能力を高める。知り合いや友人が増えるしお酒は美味しい。素晴らしい。）
ここで言う表と裏はまったくの反対のものと考えるわけではなく、それぞれ微妙に要素が被っていたりする。

表は生活の基盤であって無いとお金がなくなって生活できなくなる。
裏は人生をステップアップさせるために重要な意味を成す。

自分は裏の活動によって表の効率化や、良い考え方を持つ事ができるので、より表を高めてくれると思っています。
もちろん表があるからこそ生活できて裏の活動も出来るため大切だとも思っています。
それぞれが支えあって出来ている。

自分は表が忙しすぎたり何か他の要因も相まって裏が全く無くなり、表がうまくいかなくなった経験がある。
活力がなくなって精神的に日々の生活がきつくなったり、仕事しすぎで体にも支障が出たり。

裏が無いことのデメリットは成長が止まるため（表にも学ぶべき事は多いけれど）に仕事がうまくいかなかったりつまらなくなったり、はたまた仕事がまわってこなくなることだと考えている。
外部の人に会わないと気は滅入る一方だし、頭は硬くなって視野が狭窄していく。

物事はバランスが重要であり、それは常に探って、確かにすることを意識しなくてはいけないというのが結論かな。
自分の場合は半ば裏をメインにして良い流れに乗って生きることができれば幸せなように思うなぁという話でした。

P.S.

物事の陰陽ってこういう話かなと思った。ハレとケとか。

最近こんな記事もあった。
元自衛隊メンタル教官が教える　「折れてしまう」原因は、ストレスではなく◯◯だった

表と裏のバランスが一度崩れるとその修正にはすごく時間がかかる。
そうなることによっても学びはもちろんあるのだけれど、一度崩れたものを治すのに時間がかかるのはまたそれはそれで周りに置いていかれる焦燥感もあるのでよろしくない。

「苦労は若いうちに買ってでもしろ」という言葉は実だと思うけれど、用法用量を間違えるとキツイので無責任に言えることではないなと思った。
もちろん有難いアドバイスだとも思っています、が、言われた側はその後の自分の面倒を見るのは自分でしかないことも考えなくてはいけない。

自分が弱ってみて本当に大切なものはなんなのかがわかると同時に、わかったときには大体それを失っているから取り戻すのにこれもまた時間がかかるなぁ。
とかこの頃考える。

そういえば武術漫画の『拳児』でも教わる師匠が変わるときだったかに「これまで得たものは粉々になって失われてしまうかもしれない。しかし新たに得るものによってより成長することができる。」みたいなことを言っていた気がする。

ブログ書きにおける勘所

こんにちは、田中です。
昨日、一昨日くらいからやっと会社のブログに初エントリを投稿することを決意しました。
決意したものの、なかなか難しいと感じました。
これまでは自分で書いたものは自分に返ってくるだけだったのですが、責任の部分を意識してしまうと、良いものが天から降ってきにくくなるように感じてしまって...。
自分のブログだからといって適当なことばっか書いていいわけではないですがw

そんなことを考えてしまったので、振り返り、自戒、初心を思い出すためにブログを書く上で大切なこと、大切にしたいことをまとめてみようかと思います。
ブログだけじゃなくて発表スライドとか、何らかのアウトプットをする際にも共通するポイントが出てきます。

大切なこと

・誰に対して書くか

「誰に対して」「誰のために」というのはアプリでも文章でもモノを作るのに共通して、デザインとして大切なことです。
読む人が何を求めて読むだろうかということを考えます。

自分のために書くのでも良いです。
自分の備忘録としてだったり、新しく仕入れた知識を整理するために筆（キータイプ）を走らせてみるというのでも良いんだと思っています。

・上手でなくてもいい

ブログや技術記事を書く時、上手じゃなくても良いと思っています。
最悪間違えていたっていいと、個人的には思っています。
アウトプットすることで人の目に触れる、それによって間違いの指摘やアドバイスを人からもらえたりすることだってあるかもしれない。
自分の考えをまとめることにもなるので、まとめていて違和感があったり理解が足りないという認識が出来たらもうそれで儲けになります。
そして技術記事に関しても超立派なものでなくて良いと考えてます。
「ここの仕組みがこうなっていて」「設計的には」「アルゴリズムとしては」、etc...
でなく、「こうしたくて、こうしたら、出来た！！」とかのレベルでも良いです。
初学者の人にとっては逆にわかりやすいし共感を得られたりするので「やってみた系」には価値があります。

・しっくりこないものは駄文

とはいえ、上手な文章は書きたいし内容も濃いものにしたい。
僕はあるトピックをあとで文章にしてまとめようと思うときは大体、面白いフレーズや思考のまとまりができた時です。
これが文章の大枠の構成にぴったりあてはまると気持ちが良い、しっくりくる文になります。
しかしうまくあてはまらないと納得のいかない文章ができたりしてしまいます。
これをうまくやるには練習によるところだなと感じます。

そして駄文だとしてもできるだけ書いたものは出さないより出したほうが良いというマインドでやってます。
書いたものは出しましょう。（自戒）

・イベントレポートは鮮度が命

これには二つの意味があります。

一つはイベントに参加して得たインプットはできるだけ記憶が鮮明なうちに、ハートがアツいうちにまとめたほうがキータイプは捗るという話です。
ハートは時間経過とともに温度が下がり、良いフレーズが頭に浮かびにくくなるためです。

二つ目はイベントの話題性の部分です。
開催からの時間経過とともにそのイベントの話題性はどんどんなくなっていきます。
学校や職場で「昨日のWWDC見た！？」「こないだのWWDCは徹夜したの！？」なんて話があるのは一週間とかそれくらいのように感じます。

イベント後に懇親会があったとしても、帰ってからその日のうちにできるだけまとめることを心がけましょう。(J I K A I)

大切にしたいこと

・笑いを入れる！

これはどちらかというと、イベント登壇時のスライドなんかで特に意識しています。
「内容が難しい」、逆に「内容はイマイチ」だとしても「面白かった！」を聞いている人に持って帰ってもらえたら嬉しい。
自分はTwitter監視をしていると流れてきたりするネタを参考にしています。


今朝のタイムラインも「魔法つかいプリキュア」が良い味を出していました。
あのおばあちゃんはきっと元・プリキュア、そういう目をしていた。
キュアップ・ラパパ★

・自分を覚えてもらう！

アウトプットする事の最大の意義だと考えています。
アウトプットするとインプットが増えます。（インプットがないとアウトプットもできないですが。）
例えば勉強会で知り合いが増えてその人から濃いインプットがもらえるので、それをまとめたい気持ちに駆られます。
勉強したい！ってモチベにもなったりします。
どんどん循環させていくと良い流れができるので、なるべくそういうものに乗るようにしています。

まとめ

アウトプットを出しましょう。とにかくだしましょう。
自戒です！！！

僕は人にリアクションをもらうのが好きというのがかなりの原動力で物を作ったり書いたりしています。
ブログのページビューは監視するし、「ああ、あの◯◯の田中さん！」とか「GitHubのソースコードに質問があるんだけど」とか言ってもらったりするとはしゃぎます。
なので何かの折に声をかけていただけると嬉しいです、まる

(仮)Sendai.swift 第0回に参加してきました！

こんにちは、田中です。
3月のtry! Swiftもだんだんと近づいてきましたね、今から楽しみで仕方ありません。
ですが、予習しないとヤバそうな内容の濃さだろうなという危機感も感じています。

仙台のiOS勉強会ではおなじみの@totottiさんもtry! Swiftに出陣するとのことで、同じように「予習したいよね」という話になりこの度try! Swiftに向けたSwiftの予習勉強会として(仮)Sendai.swift 第0回を開催する運びとなりました。



エレベーター脇に貼っていただいていた案内の紙。
うん、シンプルでわかりやすい。

勉強会について

「そろそろ本格的にSwiftをやろうかな」という方が多くなってきたのかはわかりませんが、8名の方にご参加いただき満員御礼でした。ありがとうございます。

今回第0回のテーマはProtocol-Oriented Programming in Swiftでした。
「Swiftではクラスではなく積極的にProtocolを使っていこうぜ！」という感じです。
公式のWWDCのビデオとスライドを見ながら解説や議論をしていきましたので、このエントリの内容もそれに沿った内容になります。
なので、このエントリはビデオとスライド一緒に追いながら見るとより理解が捗るかと思われます。

解説・参考は以下の二つの記事を活用させていただきました。
・Swift 2で提唱されているProtocol Oriented ProgrammingをWWDCセッションから学ぶ
・Swiftにおけるプロトコル指向プログラミング

初回としてはなかなか重めの内容でしたが（自分自身理解がまだ追いついてないです；）、Swiftに関してこういった設計寄りで濃い内容を語らう場というのは仙台では初めてだったのでとても楽しかったです！

議論されたこと

継承問題

Swiftは継承できる親クラスは一つで限られています。
そのため継承するクラスは慎重に選ばなくてはいけません。
それに対してProtocolは複数採用することができるため、Protocolで代替できるところはProtocolで書いていく方が良いのかもしれません。

実装内容はサブクラスで定義したい場合

クラスでメソッドを定義する場合は実装内容を書かなくてはいけません。
しかしその具体的な内容はサブクラスで定義したい、ということがあるかと思います。
クラスで書く場合は親クラスの実装で

func hoge() { fatalError("implement me!") }

などと記述したりするのはよくしがちです。
fatalError()がカッコ悪い！
実装しないなら実装しないでおきたい！
そんな時はProtocolでメソッドの定義だけにとどめておいて、実装はそのプロトコルを採用した先でやればいいですね。

heterogeneous(adj. 異種の)とhomogeneous(adj. 同種の)

┌(┌^o^)┐ホモォ...

公式のスライドを引用します。



それぞれで定義した場合の比較です。
違いとしては引数がOrdered型かSelf型かというところ。
そしてジェネリクスを用いたソートを行っているか否かという点です。

heterogeneousの方はOrderedプロトコルを採用した型ならなんでも引数に取り、homogeneousではOrderedプロトコルを採用したSelf型を引数に取り、さらにジェネリクスで定義してあるためその型で統一されている型である必要があります。

どちらが良いかというのは時と場合にはよると思いますが、最適化具合に差があります。
heterogeneousではなんでも引数に取ります。これは何か問題があった場合は実行時にエラーが起こります。(= Dynamic dispatch)
homogeneousでは統一されている型が入ることになっている場合、異なったものを入れるようなことがあればそれはコンパイル時のエラーとなります。(= Static dispatch)

ここがheterogeneousとhomogeneousの違いです。
このあたりに関してはSwift Whole Module Optimizationの話題も出ました。
僕自身詳しくはまだ追えていないので深く言及はしませんが、最適化具合のコンパイラの設定の話かな？

Protocol Extensionっょぃ

既存のプロトコルに対して追加実装を行えるというSwift2からの機能。
Appleの標準フレームワークなどに対してもExtensionできるため、便利です。
よくStringにBase64の実装を追加するときなんかとかに使うよねーという話も出ました。
さらにExtensionで書く場合、デフォルトの実装部分も書けるためまた便利です。
デフォルト実装ができるとどこかに変更が必要になった時、クラッシュしたりすることも減ってよりセーフにプログラムが書けるのかなぁということも個人的には考えてました。

where便利そう

制約によって細かく内容を分岐させられるので便利そう。
使ってみようじゃないか。

その他

class vs structでどっちを使うべきか？
Swiftはできるだけimmutableなものを使って書いていくべき？
など。

懇親会

というかお腹空いたのでご飯と酒を摂取しに、Lucy&Gluttonに行きました。
ランチでは前から度々来てましたが、夜は初めてです。



なぜか知的飲料があった。
しかも缶で出た！
ふむ、なかなかやるではないか...！

次回はどうしようとか、シュタゲ話に花を咲かせたり、秋葉原散策の話をしたり、某アイドルグループのメンバーがタイムリープしてるネタ話をしたり...。
とても楽しいディナーでしたw

まとめ

Protocolといえば今まではDelegateを定義するときにしか使ってきませんでしたが、本来のProtocolの使い方としてはこちらの方がメインだよなぁと思いました。
ある程度予習も挟んだので濃い内容で議論できてとても充実した勉強会でした！

会場準備やイベント立てなど@totottiさんにおまかせの形になってしまったので、次回開催時はもっといろいろやらせていただきます申し訳ないです；；
次回はもう少しやさしいところから手を動かしながら入って、テーマに沿った内容で実装していくというのも面白いかななんて考えてます。
try! Swiftまでにあと2回くらいはやっておきたいところだ...。

参考リンク

以下二つは公式の内容に沿って解説されています。とてもわかりやすい。
・Swift 2で提唱されているProtocol Oriented ProgrammingをWWDCセッションから学ぶ
・Swiftにおけるプロトコル指向プログラミング

もうちょっとやさしい内容でSwiftのProtocolを触りたいという方はこちらの動画がわかりやすいかと思いました。
・Swift Tutorial: Protocol Oriented Programming - Introduction

SacrificeをSteam経由でWindows 10に入れたときに落ちる問題

あけましておめでとうございます、田中です。
年末年始いかがお過ごしでしょうか？
僕は好きなことをやりまくっています、絵を描いたり、ゲームしたり、DBを勉強したり！

先日手に入れたWinマシンでゲームがやりまくれるのでSteamを入れてみました。
昔のゲームも結構入っているようで、我が家では昔から家族でゲームをやっていたので懐かしくなっています。
そんな中一つゲームを買ってみました、その名もSacrifice。
我が家では家のデスクトップマシン3台にSacrificeを3本買って家庭内LANで遊んだりしていたほどに熱中したタイトルです。
Steamにも入っていたので早速入れて遊んでみようとしたところ、ロードが完了するタイミングで落ちる問題に遭遇しました。

問題はグラフィック設定にありました。



解像度が16bitになっているところを32bitの中から選択するとうまく動きました。

そうだよね、2000年のゲームらしいからね、16bitの設定もあるよね...、という感じでした。