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は初回の設定項目が多くて大変なようです。

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

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.

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

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

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

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

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

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

(仮)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

2015年まとめ

はいおばんです、田中です！
本日三本目のエントリです。
今度は今年のまとめをば。

今年の出来事トップ5！

1. 5年付き合った彼女と別れる

なかなかデカい。まだつい最近のことだけど、長かった分ダメージの回復や心の整理にも時間がかかる感じ。
高校からの付き合いで、当時と比べると自分が早いスピードで変わったように思う。
変わったから、人生の方向性を考えた時にズレが出たりしたのかもしれない。
仕方のないこと。別れがあれば、また出会いがある。（といいな）

2. Wantedlyでの二週間のインターン

今年のエンジニアライフで一番大きな出来事だった。
二週間東京で一人で出張して宿も確保して仕事する毎日。
楽しく、とても学びがあって素晴らしい経験ができたし、Swiftに関して「こんな書き方があるんだ！」とか、MVVMの設計に触れて「設計って面白い！！」って目覚めることができました。
自分がそれまで足りなかった部分も見つめることができて良かったです。ありがとうございました。

Wantedlyインターン発表会 from Kenji Tanaka

3. 友達とのハッカソン出場

仙台のSPAJAMに会津の友達三人と一緒に出場しました。
前から一緒に何かしたいと思っていたメンツで出場できたのは念願が叶ったし、その後もつるんだりしているのでとてもありがたい。
今年は他の友達との交流も多かった。
良い友達に恵まれて幸せです。

4. 仙台Swift勉強会

今年は自分で勉強会を主催しました。
運営は難しいですね。
最近ちょっとサボってしまっているのですが、来年のtry! swiftの予習企画も考えているのでまたやります！

5. 太極拳の型を108式を通してやることができた

やっている太極拳の108ある形を今年は通すことができました。
確かおととしくらいから少しずつやっていて、ようやく最後まで到達することができました。
まだ復習しながらの段階ですが、また来年もやっていきたいです。
太極拳から学んでいる精神面も今後発展させていって人生を豊かにしたい。

特別枠. 父との交流

今年はエンジニアとしても、同じく太極拳をやる身としても、また人として人生について父と多くを語らいました。
きつい時に救われた部分も多いし、お互いに学びあっている部分もある感覚がとてもありがたかった。
心の師と言える。
人には羨ましがられる親子関係。良いものだとつくずく思う今日この頃です。
来年から一人になるけれど、父からの多くの教えを持って東京に行くことにします。



来年も良いお年を！

自作PC入門

こんにちは、田中です。
もう今年も終わりますね。
終わってしまうのか......。
という出だしをしたけれど今年のまとめは別エントリで書きます。

このエントリでは自作PCを初めて組んでみたのでそのまとめを書きます。
Bizsparkに入っているのに長いこと使っておらず、パーツも長いこと放置していたので早くなんとかせねばと思い、windows 10のマシンを組むことにしました。

今回のスペック

今回はたまたまうちの祖父がパーツを買い換えたのでそのお古で組んでみました。

マザーボード: ASUS P8Z77-V PRO/THUNDERBOLT

「アスース」と読むか「エイスース」と読むかで歳がわかるみたいな話を父とPCパーツ屋で話をしたり。

電源: これ（型番のメモを忘れた）


CPU: Intel(R) Core(TM) i7-3370s 3.10GHZ

メモリ: CORSAIR XMS3 — 16GB (2x8GB) DDR3 1600MHz C11 Memory Kit (CMX16GX3M2A1600C11)


HDD: うちにあった500GB

やったこと

配線

PCケースはもともとうちにあったものを使いました。
その中に前使っていたPCが入っていたのでそれを掃除しながら取り外して配線の仕方と各パーツと端子について少し学んでいきました。



配線ではひとつミスをしました。
一通りつなぎ終わって、さて電源をつけてみたら起動直後に一瞬だけファンが回って電源が落ちてまた起動するのを繰り返す、という挙動がありました。
どこかのパーツが悪くなってるのかと思って、メモリ、ハードディスク、マザー、電源とそれぞれテストしていきましたがどれもおかしくなさそう。
お手上げと思ってPC屋に行ってクイック診断をしてもらったらCPUへの電源供給の線が刺さっていなかった模様。
マザーボードから供給されるからそこに刺してればいいと思っていたらそうではないんですね。(^^;
PC屋に500円払うことになったけど、500円で知識を得られたと思えば安い。
配線は無事終わってBIOS起動までたどり着きました。
最近のBIOSはすごく綺麗ですね。

HDDの初期化

家のお古のHDDなので初期化ソフトで初期化して使いました。

OSのインストール

HDDの初期化後、DVDに焼いたisoを開こうとするもThis HDD was erased!!というエラーが出てそこから先に進めません。
BIOSで起動する優先順位をBlu-rayドライブ -> HDDとするのも動かないし、直接Blu-rayドライブを指定して起動するのもできない。
ごにょごにょ調べているうちに、DVDになにかあるかと思ってmacで焼いた元のisoファイルをマウントしようとしたらできないことに気づきました。
どうにもMicrosoft Subscriptionからダウンロードしたisoが正常にダウンロードされていなかったか、ダウンロードしてくるものを間違えていた模様。
DVDを焼き直したらうまくいきました。


無事インストールできた。


xcode動かないけどね！

ソリティア

Windowsが入ったらソリティアやらないとね！


気づいたら1,2時間遊んでた

その後の使用状況

開発ではSubscriptionを使ってVisual Studio 2015とSQL Server 2014をインストールしました。
こっちのマシンを使ってサーバーサイド勉強していこうかなと思ってます。特にデータベース。


父からSQL Serverを習っている。SQL Server便利すぎでは！！これ使いながら少しずつSQL勉強していきます。
BizsparkでAzureも使えるので連携させてみたり、VM立ち上げてLAMP環境に慣れていったりもしようかななんて。
決して信仰を曲げているわけではないですよ！林檎美味しい！！

もうひとつの目的はゲームです。
ずっっっと改めてやりたかったUltima Onlineを新垢で少し始めました。昔一年くらいだけやってました。

なつかしさで死ぬ pic.twitter.com/f0giAJkSSV

— ダンボーﾌﾞﾙｰﾏｳﾝﾃﾝ田中 (@ktanaka117) 2015, 12月 29

あと太極拳の先生とガンダムオンラインをやってます。ずっと誘われていたけれどWinマシンを組んでしまったのでもう言い訳できません。
楽しいです。
今までMacだとできなかったゲームがWindowsではできます。Macだからできなくて友達においていかれることも、もう、無いんだ...!!!(歓喜)
しばらくゲームやってなかったけどこれでまたやり始めることになるかな！

まとめ

環境設定も軽く含めてだいたい二日か三日くらいかけてちょこちょこやりました。

よかったことはこんな感じ。

• 眠らせていたパーツを有効活用する機会をもてた
• 眠らせていたMicrosoft Bizsparkを有効活用する機会をもてた
• 少しだけPCの気持ちをわかってあげられるようになった
• Win使える。ゲームできる
• 便利なWin環境でDBの勉強できる

今度から東京に行くし、秋葉原とかでパーツを買いあさって色々やってみるのも楽しいかもと思いました！
（そういえば東京に行く話も別エントリで書きます。）

ここまで。

Swiftのライブラリハッカソン、「Swift2 UI/UXチャレンジ」に参加してきた

おばんです、田中です。
2, 3ヶ月ぶりに東京に行ってきました。
今回の旅の目的は主にSwiftのOSSライブラリ開発武者修行です。
最近OSSに興味があって、GitHubのTrending Repositoriesを眺めたり、Trending RrepositoriesのクライアントアプリをOSSとして作って練習してみていたりという経緯がありました。
ちなみにそのクライアントアプリはまだ開発途中だけどこちら。ほんと全然開発進んでないけど...。

TrendingGitHub
https://github.com/ktanaka117/TrendingGitHub

Swift2 UI/UXチャレンジ

サイバーエージェントさん主催のSwift2 UI/UXチャレンジという、1日でSwift製OSSライブラリ作ろうぜ！って会に行ってきました。
リンクこれ。
https://www.cyberagent.co.jp/recruit/fresh/program_detail/id=10992

なに作ったの？

綺麗で楽しい、季節そのものとか、季節性のあるイベントをテーマにしたPull to RefreshのUIライブラリを作りました。（テーブルビューとかを下に引っ張るとテーブルの中身更新するおなじみのやつ）

その名も

SeasonalRefresh

今回はちょうど10/31開催だったのでハロウィンのテーマを作ろうとしました。
こんな感じ。


Pull to Refreshでよくある、UITableViewを引っ張った分だけIndicatorが増えるようなものに火時計みたいな鬼火を順に灯していって、ロード中はジャックオランタンが灯っている、みたいな感じです。朝イチのトイレで思いつきました。

このほかにも今後クリスマス、正月、バレンタインなんかも今後対応していくとして、春夏秋冬、季節そのもののテーマも作りたいなと思っています。

どうですか、リア充っぽいライブラリでしょう！
10/31に一日こもりきりでライブラリ開発！

圧倒的リア充感！！！

SeasonalRefreshの設計

管理クラスであるSeasonalRefreshがUIScrollViewインスタンスのcontentOffsetをKVOで監視して、都度SeasonalRefreshViewに描画させたりするのが基本となっています。

依存性を低くする

最初設計を考えていた時は「contentOffsetを取れば簡単に実装できるだろー（鼻ほじ」くらいに考えていて、UITableViewのラッパークラスを作ってあげたらすぐ作れるだろうなーくらいの考えでいました。

しかしメンターさんからのアドバイスは違いました。

「優秀なライブラリは汎用性を保つためにできるだけそれ単体で機能するように作るべきである」

さっき言ったようにUITableViewのラッパークラスを作るような設計だとRefreshを実装したいだけなのにそのラッパークラスを使わなきゃいけないことになってRefreshとUITableViewの依存性が高くなってしまいます。利用する人にとって、自分で実装したいUITableViewでそれを使わなくてはいけないのは中でなにをやってるのか気にしなくてはいけなくなってストレスになります。
なので今回はRefresh部分だけ切り出して、上の説明の設計にしました。

簡単に使いやすくする

実装するのに行数が少ないと導入しやすいよねー。
ということで今回はクロージャ部分は考えないとすれば一行で実装できるライブラリにしました。

デザイン

今回こちらを参考にさせていただいてリッチにしようかななんて思ってました。
[iOS] SpriteKitとUIKitを組み合わせて、ちょっとリッチなウォークスルー画面 を作りたい

しかし実際やってみるとパーティクルとUIKitのデザインはミスマッチ。逆にチープになってしまいました。



炎をパーティクルで表現するのは良くないのかも？というのも、どうしてやればそれらしく見えるかを画像検索して考えてみたけれど、リアルな炎を空間に浮かべる時は背景や周辺環境が大切になるかも？
まわりの煙や靄、夜闇の色合いなど。
あるいはそもそも炎をパーティクルで表現するというのはそれらしく見えないのかもしれないです。あるいはめちゃむずい。

雪や桜が舞うように、パーティクルの密度を低くして、画面全体に散るような表現の方が良いのかもしれない。
ジャックオランタンの実装方法考えてないけど、同じように靄がかかったような表現が出来たら捗りそう。
レイヤーをかぶせるか、もしくは画面自体に靄のパーティクルを表現させる。smoke。とか。

ちょっとこの辺は方針転換を考えるか、微調整しまくる感じになりそうです。

まとめ

世の中そんなに甘くない！

世の中そんなに甘くないことはすでに穂乃果ちゃんが一期第3話で証明してくれています。
UITableViewを引っ張った値取れりゃそのまんま出来るなんて甘い設計では良くないんだなってわかりました。
いやむしろ良い設計は難しいけど楽しく、その難しい設計に挑戦してそれなりに実装出来たので満足感がすごいです。
今までこんな綺麗に切り分けられて書けたかなーと、ワクワク楽しい最高の気分です。
仕事でもこんな実装を、サクサクサク〜っと出来たら強いな、良いな、目指す。
直接メンターさんがついてもらって、相談に乗ってもらって講評もいただける、大満足のイベントでした。ありがとうございました！

今後

ハロウィンのテーマは残念ながら一日では北米時間なんかで考えても間に合わなかった、残念。
基本の部分は大体できたのでこれからテーマを増やしていって、クリスマスまでにリリースする目標です。
設計としてはユーザーが新たにテーマを拡張して作りやすい機構にすると良いと思いました。
ある程度のフォーマットに沿う形で、リソース突っ込んで少し書き換えるだけで自分独自のテーマが作れる、とか。
人の顔をリソースに使ったりするようなネタテーマも面白いかもしれませんww
背景なんかにアニメーションを入れられるようにしてそれも簡単にできるようにするとか、そんな感じで展開していこうかななんて妄想しています。
仕事でも使えるグラフィカルなpull to refreshの定番になれるように頑張っていきます。
が、まずは綺麗なテーマ作るところが第一段階ですね。^^)

DevLOVE現場甲子園2015「東北大会」に参加してきましたよ！

イベント前に日本酒の試飲を一杯ひっかける大学生の図。

おばんです、田中です。
今日はDevLOVE現場甲子園2015「東北大会」に参加してきました。
具体的な詳細は上記リンクから見られますが、簡単に説明すると様々な現場に関する激アツな話が10本ぶっとおしで話される激アツなイベントです。
今日はその中でも個人的に刺激を受けたトラックを紹介し、今の自分、将来の自分に活かせるであろうと受け取ったヒントを書いてきます。

前提として自分が今やっていること、考えていることとして以下のことがあります。

自分は今個人で仕事を受けていて、金額や契約に関して交渉したりしています。
それをまとめたり考えたりするときにヒントになるものが欲しいです。
エンジニアとして仕事をするときにどんなことが重要であるかということも模索しています。
仕事とは別なところでもプロジェクトを進めていて、チームとプロジェクト自体をうまく回すにはどうしていくことが必要かなども関心事です。
プロジェクトの中でメンバーにどこをまかせてどこに注意を払って進めるか、やっていて楽しい・ためになる環境を作るにはどうするか、などです。

また大学の卒業を控えていて、どんなキャリアをたどるかもいくつか考えています。
最初は大きく余裕のあるところに就職し、先述した仕事の良い進め方や開発の技術力をつけていく。
あるいは大きくはないけれども組織として成っているところに入り、裁量の幅の広いところで力をつけていく。
はたまた最初から個人として独立し、フリーランスや起業という形をとってチャレンジしていくのか。
それぞれどのパターンを取りたいとなっても共通する考えるべきことはあると思うし、もしそれぞれ個々で特に必要なスキルがあるのであればそこについてもかいつまんで知識を得ていきたい。
そんな考えがあります。

「主人がギルド開発をするようになって1年が過ぎました」

ギルドワークス株式会社 佐々木将之さん

主人がギルド開発をするようになって1年が過ぎました（2015年10月10日 Devlove現場甲子園2015東北大会） from 将之 佐々木

発表の流れとしては、佐々木さんのこれまでの略歴とどんな生き方をしてきたか、それらの点がどうつながって今ギルドワークスで仕事をしているかという内容でした。
キーワードは「ギルドワークスは開発もしています！」

発表の中で気になったのが、ギルドワークスの掲げる「正しい開発」というビジョン。
そこに関して発表の後にこんな質問させていただきました。

「正しさとは？」

僕は勉強会に参加して色々な人に会ったりしてきました。
ITという畑の中でよく聞くような愚痴であったり、自分で体験したわけではないので声を大きくして言えることではないですが、業界の「闇」のような話なども聞いてきて、常日頃それについて疑問を感じたり考えたりしていました。

• なんでそんな条件で働くのか？
• なんでそこで働くのか？
• 楽しいのだろうか？
• 労働環境過酷すぎじゃない？

など。

佐々木さんの回答の「正しさ」というのは
事実に忠実であること
正直であること
でした。

そして正しさは人や場によって変わるということ。

今へのヒント

正しさは時と場合と状況によってその時々人の中で変わるもので、常に自分がどうありたいかを問い続ける必要がある事項だと思いました。
そして正しくあるということは心身ともに健康的で気持ちのよいものであると感じるので、その正しさを遂行できる状況をできるだけ作っていくことが良い生き方につながる。
逆に言えば正しくない、なにか気持ちの悪いことは早く清算しきってしまうことが大事で、それが正直であるということにつながると考えました。
人間関係、プロジェクト、ソースコード、何にでも当てはまることかもしれません。

将来へのヒント

今へのヒントのところに書いてあることの継続が先々を考える上で一番必要かも。
いずれそれが経験値の積み上げによって、パターン化されて見えたり、自分の中で固まったものとして出来上がってくるとそれが生活や仕事をしていく上でのビジョンや哲学になっていく。
今へのヒントで書いたようなことに常にセンサーを貼っていきます。

「プロジェクト管理しないという提案」

株式会社ZIG 森 英寿さん

プロジェクト管理しないという提案 from Hidetoshi Mori

森さんが株式会社Zigで積んだリーン・スタートアップの経験の紹介とプロセス、良いところ向かないところなどが凝縮された内容でした。
なかなかスタートアップから抽出されたエッセンス的な話を聞く機会はないのでとてもレアでためになりました。

スタートアップはチキンレースである。
お金の数字として会社が無くなる時点が見えて、そこまでにどう金を得るかを考えてという繰り返しになる、のかな。
そんな中でもっとも追求しないといけないものは価値。
徹底的に無駄を排除して、価値にフォーカスしていく。
再現する確率が1%以下のバグへの対応は捨て、使われていない機能を捨てて価値を追求する。などなど

プロジェクト管理することとしないことにはそれぞれメリットとデメリットがあり、プロジェクト管理をしないやり方はスタートアップでチームでの意思決定や共通認識を早いサイクルで回すことには向いているやり方のようでした。
それは受託と自社サービスという違いもあり、フォーカスすべきところが違うからという話。
そしてそれをする場合は前提条件として以下が必要。

• 絶対的なメンバーの信頼
• 価値あるモノづくりの意識
• ホラクラシー型組織構造

絶対的なメンバーの信頼がすごく難しく、うらやましく、目指したい境地...。
シビアな経験は、濃く人を惹きつけるというのがよくわかる発表でした。

今へのヒント

今やっているプロジェクトの見直すべき点が再確認されました。
最近思っていることとして、良いチーム・良いメンバーで仕事がしたい気持ちが強くあります。
森さんと会社のチームメンバーの関係性を見ていてうらやましい感覚があって、自分もそんな仲間が持てるように目指したい。

将来へのヒント

良いチーム・良いメンバーで仕事がしたいということと、さらに自分たちのサービスで飯を食うということがしたいという気持ちがあります。
それが今すぐなのかはわからないけれど、条件が整ったと思える時があればやりたいです。
それは以前行ったWantedlyでのインターンの経験が深く印象に残っているからというのが理由な感じです。
自分の考えるサービスが人に使われて、自分の書いたソースコードが生に、生きた状態でサービスにそのまま反映される責任感と楽しさ、そんな感覚の片鱗を味わったインターンだったので深く刻まれています。

Zigの方々と話をさせていただいて感じたのはそれの難しさときつさ。
新たな何かを生み出すのに足る自分であるか、仲間がいるかというのを常に観察しながらでないと機会を見失うだろうというヒントを得られました。

まとめ

上の二つ以外にもこんな感じの発表が8本、合計10本ある激アツなイベントでした。
数として現場を渡り歩いてるわけではないので今はまだまだですが、また今度開催されるのであれば、次のころにはまた少し現場を経験していると思われるので登壇側で喋ってみたいです！

あと嬉しかった点。
イベントの最後に今回のイベントで得たものを参加者同士で話し合って共有するという時間で、森さんに「喋り慣れたね、うまくなったね」と言ってもらえたこと！！
以前から森さんとは知り合いで、度々イベントでお会いさせてもらったりしていた（ハッカソンで同じチームだったり、TDDBCでテストコード書いたり。あの時はなにもできなさすぎて申し訳なかったです...。）ので、少しは成長できたかなと嬉しくなりました。よかった。がんばろ。

Dokugaku-Dojoに入門してみた

こんにちは、田中です。
先日知り合いのFacebook経由でDokugaku Dojoというものの存在を知り、面白そうなので入門してみました。

Dokugaku Dojoってなに？

詳しくはサイトの方を見てもらったほうがいいと思うのですが、独学仲間で集まって一緒に独学したり情報共有したり、成果発表したりするグループのようです。
Google SpreadSheetを使って自己紹介したり、Slackを使って日頃の独学状況を共有したりしています。
appear.inを使って同じ時間帯に集まる人たちで画面共有をして一緒に独学していったりもしています。
適度な緊張感のもと作業しないとグダる傾向が自分にはあるので、ここに特に魅かれました。

月一でミートアップを行って実際に会って成果発表したりなども行っているようです。
基本的には東京のほうでやるそうですが、オンラインでの参加もできるそうで仙台在住の自分としても嬉しいところです。

参加時の面接について

サイトで参加申込をすると主催の深山 雄太さんからSkype面接をしていただけます。
自分と深山さんの間にはWantedlyでお世話になっていたというつながりがありました。
内容はDokugaku Dojoに何を求めて参加するの？っていうことをすり合わせたり、Dokugaku Dojoを良くする上でのアンケートみたいな感じでした。
あとは簡単な自己紹介をしたり、最近独学なにやってますかの独学状況の話とか、影響を受けた本はなんですかーとかの楽しい世間話。
深山さんは物静かでダンディズムある感じの方でした。

感想

自分もまだ昨日面接しただけでオンライン独学道場はまだ参加していないという状況ですが、深山さんとお話させていただいた感じだと良いグループそうだと思いました。
作業効率高まりそうというのと、参加者はなにかしら独学したくて集まってるので良い意味で意識の高い人たちが集まっていそうだという点が良いです。

あと昨日話をしていて、自分の学習を振り返っていたらあんまり独学っぽくも無いのかなと思ったり（：＾＾）
自分はいろんな人のお世話になっていろんな場でゲリラ的に経験値積んでいったタイプなのかなと。
今まではそんな感じでしたが勉強の仕方はその時々で変化します。
最近はある程度一人でやっていく方法がわかってきたので、もくもくと一人で本を読んだりコードを書くフェーズに入ってきたのかなと思います。
なのでDokugaku Dojo、利用させていただいていこうと思います！

Wantedlyインターン12日目〜最終日〜

おばんです、田中です。

俺はインターンを終わるぞ、ジョジョォー！！

ということで最終日でした。

ちょうど今日がアップルに審査を投げる日で、リリース日だったのでバグ修正とその他リファクタリングをしていました。
直しなどを行っていたのですが、今日が一番ビルドに時間がかかったひな気がしました。
直しなので一行二行書いた段階でデバッグをしたいということが多かったのですが、その度に20分。
作業は思うようにいきませんでした。
しかしなにかが覚醒したのか今日はリファクタリングをしていて、複数のクラスに影響がある部分の修正で結構重かったのですがどこか見晴らしよく、見通しが立つ感じで作業を進めることができる瞬間がありました。
なにかレベルアップ音がなっていたかもしれません。
メンターの森田さんの修正する背中を見て、なにかを吸収したように感じました。それが少し出た。
その感覚が続くようになったらかなり良い！なので帰った後もその感覚を忘れずに作業に取り組んでいきます。

だいたい例えると「読める、読めるぞ...！」と、某大佐を思い出していただければだいたいあんな感じです。

しかし結局、少しデバッグが足りなかったりして挙動が確認できていないので、僕が今回実装していたDropbox連携のところは次回リリースでの組み込みとなりました。
組み込まれてくるのが楽しみです。
バージョンアップでなく、新しく申請するアプリの神聖なリリースに立ち会うのはすごくハラハラしましたww

お昼は社員の相川さんという方とご一緒させていただきました。Wantedly開始から四人目の人です。お昼は親子丼です。



相川さんはWantedlyでインフラなどをなさっていて、インフラのことを色々と熱く教えていただきました。
インフラって地味なイメージがありますが、やっていることは本当に基盤となる超重要なところで、それがパフォーマンスにつながったりする。そんな話を聞いて、だいぶイメージが変わってインフラのかっこよさとか華やかな部分を感じることができてとても楽しい時間でした。
言語にも詳しくて、ああ、好きなんだなっていうのをすごく感じましたw その人の話し方を聞いてるとわかりますよね。

あとは最近話題のDockerってなに？ということを質問したり。
あれはタスクマネージャなんかのプロセス一つ一つをコンテナという単位で区切っていくような仕組みのことで、一プロセスに一コンテナの環境を用意するのでそのプロセスに最適化されるところが良いそうです。
例えばサーバーなんかだとこれを動かすには環境としてあれも必要これも必要となりますが、それを最小構成にすることで立ち上げを早くしたり一プロセスに作業を集中させることでとても効率的なんだそうです。
曖昧な説明なのは、まだちゃんと理解してないからです！便利そうなので少しいじったりしてみたい。

リリース後と僕のインターン最終日ということで仕事終わりは飲みに！！
実は「最終日飲みに誘われるかな、まだかな」、って期待してたのですごく嬉しかったですww



でもリリース後の飲み会なんてまあデバッグ大会ですよ！ww
それも含めて楽しかったですがw
やっぱりお酒は美味しいですね、今日はさらに肉も美味しく感じたので最高以外の言葉が出なかった。
あとWantedlyはIT系には珍しくオタク色が薄いのでラブライブについて熱く語って布教しました。
その甲斐もあって、その素晴らしさの一端をお伝えすることができたようで凛ちゃんのLGTMいただきましたッ！！
めちゃくちゃやる気出るので二次キャラgifLGTM駆動開発を推進していきますこれから。



覚えておいて欲しいのは「好き」と「推し」はまた違うということです。
ここ大事。

そんなこんなであっという間の二週間。
今日ふと帰り際に寄ったトイレの鏡で自分の顔を見て気付きました。

「あっ！もう二週間か！！」

と。
それだけ充実してたってことですね、本当に終わったあとは一瞬でした。
疲れて感覚なくなってるところもあると思うけれど、仙台にいたらとてもできない経験をさせていただいて、本当にWantedlyさんありがとうございました。
チームの方々、誘っていただいたのもありがとうございました。何もしらない自分の面倒を見てくれて丁寧に教えていただけて、ありがとうございました。

Wantedlyさん本当に良い会社でした。
技術サイドからは、普通こんなにリッチな開発の仕方できないよ、と思うようなところも社員さん個人個人のスキルが高いので実装できてしまうという。技術だけでなくコミュニケーションや開発の進め方の部分でも。
中の人柄や文化もあり得ないほどの居心地の良さでした。
こんな世界もあるんだと、楽しみだし、希望が持てるし、頑張ろうと思いました。
もっとスキルを磨いて、もっともっと高みに昇りたい、そう思える二週間でした。
ありがとうございました。

Wantedlyインターン11日目

おばんです。
残すところあと明日1日です。
残タスクの容量も良い感じで、明日の仕事でうまくカタをつけられそうです！！
あとは細々としたところをどれだけ片せるかみたいなところもありますね。

今日はこの二週間のインターンの成果発表会をやりました。
なぜDropbox連携したのか、実際どんな機能を実装したのか、残タスクと今後の展開はなどよくあるパターンです。
なぜDropbox連携したのかということに根拠を持たせるために、メンターの森田さんのアドバイスで数字（データ）を少し拾ってきたりしたんですが、普段そんなことしないからそれで正しいのかわからず！
でも確かに、少し数字をつけてあげるだけで多少なりとも説得力みたいなのは出るかもしれないと、思いました。
「へぇー、そうなんだ」、みたいに思ってもらえると。
今後何かで発表する際はその手もアリですね。というか「そうしないといけない」レベルの話だとは思うのですが。

成果発表の他に、今やっているiOSプロジェクトの全体の開発構成についてなど話をしました。
MVVMのモデルを全体通して使っており、SwiftBondとSwiftTaskをうまく利用しているのが特徴で、この規模のプロジェクトでこの構成をとってるプロジェクトもほとんどないのではないかという話。
聞いてくれていたのは会社の方々ですが、普段iOSの開発をしているわけじゃないとか、別のチームでやってますという方々だったので結構聞き入ってもらえる話だったんじゃないかなと思いました。
ただ、自分も特にSwiftTaskに関しては発表に向けた突貫工事みたいな感じだったので、細かい質問に答えられなかったのが悔しかったのでちゃんと勉強します。

自分では準備不足だと思っていたのですが、同じチームの杉上さんに褒めていただけたのでうれしかったです。
普段から発表には必ずネタを入れていこうというスタンスが功を奏しましたw
今日の発表、LGTMでした。（LGTM = Looks Good To Me.GitHubのレビュー後によく使われてます）

発表資料はSlideShareなどにあげたいと思っていますが、まだUpして良いか確認していないのでそれが済んだあとで公開します。
駄目でも差し障りのない技術部分に関してなどあげていこうとおもいますので、乞う御期待！

写真は今日のランチの焼き魚定食です。夜も0時を近くなってまいりましたが、お納め下さい。
明日の最終日も頑張ってきます。

Wantedlyインターン10日目

おばんです、田中です。
インターンも残り二日となりました。
自分の担当する部分もラストスパートです。たぶん。なにもなければ。

今日はなかなかにもくもくと作業をしていたのですが、メンターの森田さんとライブラリについてなどお話をしました。
とりあえずAwesomeSwiftとTrendingSwiftRepositoriesは見ておくと勉強になるというアドバイスをいただきました。
AwesomeSwiftは文字通りすごいライブラリまとめみたいなものらしいです。
森田さんのSwiftyDropも載っているのでぜひ！
とりあえず仙台に帰ったらこのあたりを見ながら勉強します。

今日もまた以前と同じようにプロジェクトのちょっとコアな部分の修正をしていたのですが、その中で出てきた書き方に少し苦戦しました。
どこかというとクロージャを使ってクラス間で処理の移譲を行っているところでした。
クロージャを変数に入れてオブジェクト化し、別クラスのプロパティに渡してそのクラスの任意の場所でそのクロージャを発火させるという流れ。
これがどこで処理を保持していて呼び出しているのかが若干読みづらいかと思ったのですが、慣れると使えそうな考え方だなと思ったり。
なによりうまく書かれていたのが、その移譲するオブジェクトのメモリ管理。クロージャの内容が別クラスの方から元クラスで呼べるメソッドを呼び出すという中身で、オブジェクトの破棄に気を使わないといけないなと思ったけれど、自分が今まで知っていたdelegateやKVOによるメソッド呼び出しとはまた違うやり方が知れてとても面白かったです。
このあたりは特徴的だったのであとでまとめ直します。

明日はインターン最終日というわけではないですが、成果発表会を行います。
明日の17時くらいまでに実装できたところなどに関して話そうと思います！
ああ、その用意をこれからしなきゃw
ということで今日はこれまでですー、お疲れ様です。
あ、お昼にとうしょうめん食べました。
真っ赤なのが来た時は「うわあこれどうしようホンマ...とか思ったけど」思っていたより辛くなかったです、仙台の大河原の方が圧倒的にヤバい。美味しかったっす！