2016年4月3日日曜日

第六回 カジュアルSwift勉強会@青葉台に参加

お疲れ様です。 ZuQ9->Nnです

2016/04/02(土) 第六回 カジュアルSwift勉強会@青葉台が開催されたので参加しました。
今回の目的は勉強会の参加ってよりも、自分の発表です。

去年から、発表するする詐欺を続けてしまい。
気になってたので思い切ってやってみました。
なんでも、勢いって大切ですよね。

発表内容はクロージャについて。
資料にも書いたように自分が苦手だったので勉強目的です。

発表の反応は。。。微妙だったようです。
かなり久しぶりの発表だったため、
それだけでいっぱいいっぱい、
発表後も頭が真っ白な感じ。
もう少し、余裕が欲しいかな。
勉強会そのものを楽しめた感覚は少なかったですね。
針の筵みたいな。せっつかれた感じで過ごしましたww

個人的には、発表そのものがグダグダにならないこと。
かといって早口になりすぎないことを目標としていましたが、
やはり、説明が早すぎたかな。それは途中で気がついたんだけど
もはや修正ができなかった。。orz..

こぼれ話というか、発表時にまとまらなかった内容

クロージャとプロトコルは似ている
発表資料にもあるように、クロージャは
関数の定義のみ行い、実装を呼び出し元に任せる事が可能です。
この資料を作っている途中に、それってプロトコルと同じやんって思ったんですが

住み分けというか、どういった違いがあり、
どういったシチュエーションでプロトコルと
クロージャを書き分けるのか、具体的な良いサンプルが思い浮かばず
また、話の流れをそちらに向ける事ができず、断念しました。
ここらへんもう自分の中でもまだスッキリと理解しききれていませんね。

クロージャもリテラル
主催者の熊谷さんはよく他のSwift勉強会でもリテラルの話をされています。
関数オブジェクトの説明を書いている時に
関数が値、つまりはリテラルである事がわかったんですが、

なにかプロトコルが定義されているんだろうか?
Objective-Cのblocks構文は関数ポインタだったけど
そもそも、value typeなのか?reference typeなのか?
reference typeぽいけど、それじゃあvarで受けた時、変更できるのか??
(できそうな感じだけど、方法がなさそう。。)
こちらも深堀りしきれず、理解も中途半端な状態ですね

Swiftの書籍に思うこと
よく、Swiftの勉強をしているときに、書籍を購入したりするんですが、
大概iOSのAPIを利用してObjective-C時代のやつを
単にSwfitに直しているパターンが多いなぁと感じます。

特に今回のクロジャについては、入門書ではあまり扱われないし
詳解Swiftのような書籍は文法の説明のみで
実際のアプリで利用しているサンプルを見れなかったりします。

また、解説も難解で、あまり、頭のなかにスッキリ入ってこず
第一級関数みたいなキーワードだけが目について
何それ美味しいの?みたいな感覚が残ります。

勉強会の懇親かなどで、クロージャが苦手って話をしても
慣れたらわかるみたいな荒っぽい返答しか返ってこなかったり悶々とします。
そういう人って絶対に慣れるためのステップって示さないんですよね。
本当に理解してるのこの人??って疑問に思います。

ならば自分が分かりやすいスッキリとした資料を作ってやる。。
みたいなノリもあったんですが、改めてまとめると
本当に自分が理解してたのか?あるいはこの捉え方であってるのか?
みたいなのが自信がなくなってきますね。

いろんな勉強会で発表している人は、
自分の発表内容が正しいのかはどうやって担保してんだろう
改めてその辺も気になります

あと、やはり、業務が忙しくなると気になりながらも
勉強会の手がとまるので、発表者の方の準備の大変さも
自分がやってあらためて感じたり、今回は色々勉強になりました。

この発表の機会を与えてくれた、主催者の熊谷さんには
あらためて感謝とお疲れ様でしたを言いたいです。

最後に、不吉なフラグを立ててしまいましたが
アウトプットの重要性、そのためのインプットの大切さを
体感できたので、今年は最低、後1回は発表します。。

2015年6月30日火曜日

Swift 2 (& LLDB) シンポジウムに参加

お疲れ様です。ZuQ9->Nnです。
2015年6月28(日) Swift 2 (& LLDB) シンポジウムが開催されたので参加しました。
場所は渋谷のスマートニュース株式会社さん。

そうあの有名アプリの会社さん 参加者はオーディエンスの
申し込みだけでも80人の大規模な勉強会

まずは、岸川さんからの今回の勉強会の趣旨、
やり方などの説明があり What's new in Swift2として
新しいSwiftのトピックを解説
  • Protocol Extensions
  • Error Handling
  • Guard Statements guard let ... else {}
  • Defer Statements defer {}
  • Pattern Matching
  • OptionSetType
  • Availability
  • Function Pointers
  • Open Source
の各トピックが話のネタとして提供されました。
このあとguard、@noreturnについての議論がパネリスト内で行われました。
一応アイスブレイクだったようなのですが、かなり議論がもりあがりました。

続いては、sonson_twitからSwiftは何処から手をつけていいかわからない。という議題が
この話は、かなり個人的に共感できる部分がありました。
各パネリストからの回答があり、話は、classとstructをどちらを使うか等の話に及んだり
class は全部finalで良いのかといった意見もとびだしました。

ここで一旦休憩があり、続いては

@_ishkawaの「Protocol Extension」

Protocol Extensionはインターフェースしか定義できなかった頃に比べて
 大幅にプログラミングを変えるということで
Swift1時代と Swift2時代のコードを比較しながら説明がありました。

 Protocol Extensionでデフォルトの実装が可能になり、
Objectve-CでのProtocolでのoptional と同じことができる
標準ライブラリのmap関数を例に出し、どのように変わったかを

sortedを例として型制約付きのグローバル関数が
型制約付きのProtocol Extensionに変わったことを
非常にわかりやすく説明されていました。

Protocol Extensionで抽象クラスの継承の問題
抽象化による型の損失の問題を解決できるので
classで設計するより抽象化のコードには向いているそうです。

@es_kumagaiさんの「Swift2.0 大域関数の行方から」

Swift2.0で衝撃的な出来事として大域関数の大幅の削除で
移動先のほとんどがprotocolに行ってしまったことがとても気になったそうで
Protocol Extensionは大域のジェネリック関数を全て置き換えるものなのかなと

また、Protocolになった場合での名前空間の衝突の問題。
型エイリアスの衝突を話されましたが、あまり問題にならないのではと結論
Protocol Extensionは積極的に使っていきましょう
大域関数に残ったものは使い分けが必要かもというお話でした。

再び休憩の後

@cockscombの「私とスウィフトとエラー」

Swift2.0のError Handringについて。昔はNSErrorのポインタからtry catchへ変わったこと
クロージャーのError Handring、非同期処理のコールバックでのエラーハンドリングの例を enum ValueOrErrorを定義してはどうか。。
エラーハンドリングはSwitch文のように網羅的であるかどうかなどを説明されました。
rethrowsなど知らないトピックがあり勉強不足を感じました。

@inamiyさんの「Swift 2 Error Handling V.S. Result

同じくError Handlingについて、今までObjective-C時代のエラー処理から Either/Resultに話が及び、Swift2になりtry catchにエラーの型が緩いのでResultよりも良さげだけど本当?
エラー型がゆるすぎる、非同期の処理では扱いにくい等の問題を説明。

非同期はLazy throwingという仕組みを考えられ、そちらはどうかと提案
やっぱり、Resultが今の所良さげかなと結論。

Resultにしたときの問題点、デメリットも説明。
最終的にRustを検討。Resultにたいしてthrowを行うことが綺麗で良いのではとのこと

勉強会自体、かなり長丁場で、後半かなり聞いているだけでも
疲れるか感じだったのですが、共感できる疑問点もあり非常に有意義に感じました。

また、いつもの発表会形式とは趣が違い、他人の疑問点、思い
試行錯誤などを垣間見られたのは貴重でした。

2015年4月25日土曜日

「iPhoneアプリ PresenSlider1.0」をリリース

お疲れ様です。ZuQ9->Nnです。
2015/04/24 Apple Watchの発売と合わせて
Apple Watchでスライド操作ができるPresenSliderというアプリをリリースしました。

PresenSliderはiPhoneにPDFのドキュメントを同期させ
Apple Watchで操作するドキュメントビューアーアプリです。

スライドの画面はAir Playを通じて大画面に出力できますので
プレゼンテーションをやるときに手元で操作
大画面で表示という使い方を考えてこの名前にしました。

Apple Watchで操作できるって点が一番の売りなので
iOSのサポートは8.2以降となっております。

Apple Watchとアプリの連携はこんな感じになります。

このアプリの元ネタは、コクヨの黒曜石という
プレゼンテーションを操作するガジェットです。


勉強会で何度か使っている人をみて、面白そうだなと思いつつも
あんまり頻繁にプレゼンするわけでもないので買わずにスルー

アプリを出す出す詐欺を続けて、悶々とした日々を送っていたところ
Apple Watchの発売を聞き、同じようなの作れないかとチャレンジ
なんとか発売日にリリースを間に合わせた感じです。

MicrosoftのPowerPointとAppleのKeynoteのアプリが
同じようなApple Watchでのリモート操作に対応し
かなりテンションがた落ちしてしまい、正直リリースやめようかとも

せっかく作って発売日までに審査も通してしまったので
もったいないから出してしまいました感。。

個人的に、やはりパワポやKeynoteのファイルが直接使えない
わざわざPDFにして同期ってのが気にかかっているので
今後はその辺の不満点を解消していけるようにと考えております

気になった方はこちらのリンクから
 
ダウンロードして星一つでもいいのでレビューとか書いていただけると
励みになりますのでよろしくお願いします。m(_ _)m


2015年2月26日木曜日

Realm Tech Talk with JP Simard #2に参加

お疲れ様です。ZuQ9->Nnです。
2015/02/23(月)Realm Tech Talk with JP Simard #2が開催されたので参加しました

場所は恵比寿、広尾の株式会社Fablicさん、フリマアプリFrilを作成されています。
参加人数55名の講演会形式の勉強会。

実は、iOS開発に携わっていながら、このRealmが何かまったく
前提知識無しの状況で参加しました。まったくもってお恥ずかしい話。。

下記はイベント募集ページからの引用です。。
Realmにつて。SQLiteやCore Dataの代替テクノロジーとなるべく開発されている、
非常に高速でメモリ効率が良く、使いやすいAPIを備えた
iOS/Android両方で使用可能なモバイルデータベースだそうです。

会場ではピザと飲み物が用意されて、リラックスしながら話を聞くスタイルでした。

Realmの作者JPさんが英語で、先ほどの引用のような
Realmの特徴、なぜ、作ったかなどの説明がありました。

Realmは、なんといっても速い、それだけではなくオブジェクト指向で
プログラムを記述できて扱いやすいのが最大の特徴のようです。

SQLite直接と比べるとどうしてもおそくなるようですが
FMDBのようなObjective-cでのラッパーと比べるとかなり速く処理するそうです。

公演のあと質問タイムではかなり多くの質問がありました。
特に気になったのは、ディスクに直接書き込むから速いのはなぜか?
という質問でメモリからのディスクに書き込む処理を省くことで
速度を実現しているとの答えでした。

質問タイムのあと、少し休憩があり休憩のあと
Chatwork宮下さんがAndroidでRealmを導入した時のお話をLTでされていました。

なんでもAndroidでデータ永続化の選択肢が増えたのは大変嬉しかったそうです。
しかし、バージョンアップがかなり早く、それなりについていく覚悟が必要だそうです。

普段はWebと連携するアプリの作成がメインであまり端末にデータを保存しないのですが
他の技術者さんの話を聞くとパフォーマンスの改善も含めて
端末、ローカルにデータ保存するケースも多いそうです。

公演は常に英語でしたが@kitasukeの非常にわかりやすい通訳で
ストレスを全く感じず、時間が短く感じるくらいでした。
いや、ほんと、かっこいいし憧れますね。。
今後もRealm系のイベントは機会を作って参加予定です。

2015年2月23日月曜日

第五回 よこはまクラウド勉強会 「そろそろGitを触ってみたいと思っている方に向けて」に参加

お疲れ様です。ZuQ9->Nnです。
2015/02/21(土)
第五回 よこはまクラウド勉強会 「そろそろGitを触ってみたいと思っている方に向けて」
が開催されたので参加しました。
場所は、横浜の株式会社アットウェアさん。
参加人数15名ほどの講義とハンズオン形式を合わせた勉強会

まずは、Gitについての基本知識として
そもそもGitとは、分散バージョン管理とはの説明

集中型のバージョン管理と分散バージョン管理の違いについて
分散管理型のメリット、ソーシャルのGitHubなどなどが説明されました。

プロジェクトでGitを活用した事例を説明。
ここでアジャイルのスクラム開発、スプリントについて
自分のプロジェクトでGitを使い始めてから慣れるまでのプロセスを紹介。

痛い話として
  • Gitはなんでもできるのでリポジトリを簡単に壊せる。
  • 誤った履歴を操作
  • このツール大丈夫?
失敗して覚えるということもある。
大人数開発で目がいかないと危険
バックアップ重要だそうです。

最後にプロジェクトで使った時の感想として。
  • 短いスプリントでのブランチ開発は快適
  • 大規模プロジェクトでは、workflow機能を使うべき
  • pull request形式でmerge
  • 最初はトラブルが起きることを想定しておく
  • svnより結果としてgitを使ってよかった
とまとめられました。

その後少し休憩がりました、休憩時はこんな感じの
お菓子もくばられリラックス

休憩のあと、Gitのハンズオン開始、
ハンズオンは、ドットイントールを使用しました。

サーバーに環境を用意していただいて、
基本サーバーでLinuxのコマンドを叩きながら

まずは、git --version、which gitなどで
インストールするの確認

作業エリア、ステージング、リポジトリの説明
git config -global user.name、git config -global user.emailで
ユーザー名、emailの設定これは必須しかし実在している必要ないとのこと。

git initで初期化、vimでindex.htmlってファイルを作成
ファイルにline 1を入力し保存、git addでステージングに
git commitでリポジトリに保存。git logでlogの確認

index.htmlを編集、保存しgit statusで内容確認
git checkoutで変更の取り消し、git diffで差分確認

git add .でディレクトリにあるファイルを一気にステージングに乗せたり
ファイルを削除する場合はgit rmを使う
.gitignoreファイルで無視するファイルを指定する

git branch hogeでhogeブランチ作成、git checkout hogeでhogeブランチに移動
masterブランチのindex.htmlとhogeブランチのindex.htmlの一行目を書き換え
git add、git commit、git mergeでmergeして、コンフリクトをわざと起こす
手動でコンフリクトを解消し、commit、hogeブランチをgit branch -d hogeで削除

最後は、かなり疲れてきて、ついていくのがやっとでした。
gitそのもじゃなくて、まるでアジャイル系の勉強会のような
開発プロセスなどにも言及されていて、参考になりました。

話を聞いていて、自分の現場の遅れっぷりに不安を感じたり、
他人の現場を羨ましく思うだけなんですよね。。
かといって、具体的な改善の行動はいつも何もしないけど。。


2015年2月16日月曜日

Swift Developers MeetUp in Tokyoに参加

お疲れ様です。ZuQ9->Nnです。
 2015/02/15(日)Swift Developers MeetUp in Tokyoが開催されたので参加しました。
場所はラトゥール新宿、夜19時から、参加費1000円の
Developerが集まってワイワイする感じのイベント


まずは、主催者さんからの挨拶があり。
そのあとすぐに交流会、ピザと飲み物が振舞われました。
元来、人見知りもあるので、ちょこちょことしていた感じですね。
なんか、それほど交流できたかは疑問です。

そのあと、LT大会5名ほどが発表されていました。
中には大学在学中にスタートアップをしたりとか
若いなりの勢いを感じました。。少しここらへんはうらやましかったり。。

TLのあとは再びピザ第二弾

さすがに、この時は、かなりお腹いっぱい感が強く
ほどんど食べれず、お酒も入ったからか、やたら眠かったです。
22時くらいまで、ぐだぐだ過ごし、最後はみんなで記念写真。

今後、この会は東京で、Swiftが盛り上がるようにハッカソンや勉強会
交流会も積極的に行うコミュニティとして活動するそうです。

2015年2月15日日曜日

iOSオールスターズ勉強会に参加

お疲れ様です。ZuQ9->Nnです。
 2015/02/14(土)iOSオールスターズ勉強会が開催されたので参加しました。

場所は恵比寿のデジタルガレージ/Open Network Lab
参加費1000円、申し込み人数350人という大規模な発表会形式の勉強会
著名なiOSのデベロッパーが発表するとのことで参加しました。

LINE株式会社石川洋資さんの『Adaptive Collection View』

iPadでUICollectionView、iPhoneでUITableViewで実装したほうが
良さそうなUIを実装をする場合。UICollectionViewで全て実装してしまおうとの提案

UICollectionViewでUITableViewっぽいものを実装するのは割と簡単だそうで
レイアウトもUICollectionViewFlowLayoutを使えば良いとのと
estimatedItemSizeを設定し、UICollectionView
LayoutAttributeをUITableViewCellに似せる

その後、作ったアプリのデモをされました。
行は固定のサイズだけでなく、可変の値でも対応可
一つのViewconControllerとCellでiPhone、iPadの対応が可能

セルのサイズ計算はself sizing cellを利用する
iOS7の対応の葉愛はself sizing cellを真似て
systemLayoutSizeFittingSize HeightForRowAtIndexPathを呼ぶとのこと

iPhoneとiPad対応する場合は同じコードを2度書かないなど
耳が痛い忠告もありました。
全く知らないテクニックが紹介されていて大変参考になりました。

株式会社ユビレジ岸川克己さん『Swift製ライブラリの良い書き方を考える』

iOS系の勉強会で何度もお会いしている岸川さん。
ご自身がgithubで公開されているUICKeyChainStore をサンプルに
人に使われる時にどのようにすれば使いやすいコードになるかって話

例えば、Optinalの取り扱いについて、オブジェクトがOptionalはnilの可能性があります
Objective-Cでは割とカジュアルにnilを渡していたのですが、
Swiftでは型が厳格なので出来る限り、Optionalでない値を引数に渡す

メソッドにデフォルト引数を使う場合は、保管が、まず
デフォルト引数のある補完候補があらわれるため
使いずらく、メソッドのオーバーライドで実現をしている
クロージャの場合は、デフォルト引数のほうが使いやすい

戻り値が違うだけのメソッドのオーバーロードは
asで型を明示しなければならず、コードを書くリズムを壊す。

エラー処理はObjective-CではNSErrorのダブルポインタで実装されるが
SwiftではEither型を使うほうが気持ち良く書ける。
クロージャでエラーを扱う場合は、今まで通りNSErrorを
エラー処理は独自のErrorオブジェクトより標準のNSErrorで良い

ライブラリを公開するときはPlaygroundを付けてあげよう。
Functional styleは、こちらでも書けるよ。。くらいに付けてあげる
岸川さん個人的な見解だそうですが、Either型なんて全く知らなかったので
かなり影響を受けそうですね。。

ヤフー株式会社佐野岳人さん『let UIWebView as WKWebView』

iOS8からサポートされた新しいWebView WKWebViewについて
UIWebViewとインターフェースは似ているが互換性がない。
ナイーブな下位互換対応すると分岐が大変

方針としてラッパーで1.隠蔽する、2.UIWebViewをいじることを説明
いつかiOS7のサポートを切るときに、苦労しないようにとのこと

Wantedly inc杉上洋平さん『通信のパフォーマンス改善』

Wantedlyのアプリで通信のパフォーマンス改善
cocoapodsで対応しているPony Debuggerというライブラリを用いると
通信を解析され、JSONのリクエストより画像の容量が多いことを発見
画像はSDWebImageのライブラリを用いて作っていたので
そちらのコードを解析、なんと不具合をみつけて
Pull Requestを行いmergeもされたそうです。

画像を優先付け、画像のフォーマットをWebPに変える
それに伴ってサーバー側も変更
改善したパフォーマンスはiPhoneの設定を変更して
確認することが可能だそうです。

かなり参考になりましたが、SDWebImageを
実プロジェクトで利用してないんですよね

グリー株式会社矢口裕也さん『効率的なアプリ開発のベストプラクティス』

なるべくはやくつくってしまいたい。
品質は必要十分である 効率的に実装するにはどうしたらよいか

そんな時の大原則は「やることを減らす」
具体的には
  • UIの実装コスト
  • 通信の実装コスト
を減らす、UIの実装コストを下げる具体的にはAuto Layout、Storyboard、Self Sizing Cell
通信の実装コストを下げるには、ほぼ実装に依存するが
大原則はサーバー側に任せる。APIは共通化、RESTにとらわれない。
JSONModelやMantleなどのライブラリで扱いやすいJSONを返してもらうなど

サーバー側仕様変更で問題になるもの
綺麗なRESTFul APIサーバー、汎用的なAPIであることを理由に
特定画面に特化したAPIを断られることが多い

レガシーサーバー
触るのが怖い、同じような処理をする新APIを実装した場合にデグレがおこる

サーバー側をどう説得するか
パフォーマンスの向上のメリットを説明
最終手段として中継サーバーをたてましょうだそうです。。

フリーランス 堤修一さん『WatchKit を実際にさわってみて』

いつもブログでiOSの技術を発信している堤さん。
最近ではBLE関連の記事が多いのですが、今回はWatchKit

はじめブログで記事を書いたときは、なんにもできねーなって印象だったWatchKit
実際さわってみると、意外とできることが多いことを発見。
まずは、WatchKit ExtensionはiPhone側で動く等WatchKitの概要を説明
  • アニメーション
  • テキスト入力
  • カスタムUI
これら3つの内容について詳しく説明
アニメーションについてはstaticアニメーション、dynamicアニメーションの実装
テキスト入力については、まだシュミレーターで確認できない。
カスタムフォントについては、iOSと同じ方法でやったらできた。。

Appleの公式サンプルでみると、画像を複数枚用意して
カスタムUIを実装するのが今の所ベストプラクティス??
インターフェースのオーバーレイぽいこともbackgroundを活用してなんとかなる
検証サンプルコードは、空気をよんで近く公開予定だそうです。

クックパッド株式会社所友太さん『リリース前の確認方法まとめ〜長生きするために心臓に悪いリリースはもうやめよう』

iPhoneプログラミングUIKit詳解リファレンスで有名な所さん。
 リリースボタンを押すときに 安心してボタンを押せるために
Internal Testersを使っての確認を説明

まずは、AdHockとプロモーションコードを使ってのテストでは
厳密な意味で違うものをテストする

Internal Testersとプロモーションコードを使ってのテストでは
Appleの審査が始まる前に始められるという違いがあることを説明

Internal Testersは、是非利用すべきメリットとして

  • AppStoreで公開されるアプリと同じものをテストできる
  • Appleの審査前にテストできる
デメリットとしてiOS8以降でしかテストできない
テストできる人数に制限があることを説明

次にInternal TestersとCIについては、
競合するものではないので、両方利用すべき。

万が一事故が起きた場合はBuild Detailsのスクリーンショットを撮る
実際に公開されているアプリのipaファイルをバージョン管理しておくことだそうです

クラスメソッド株式会社平井祐樹さん『エンジニア戦記 ~ 小さなチーム 大きな未来 ~』

多くのiOS系ブログ記事を投稿されているクラスメソッドさん
クラスメソッドさんでは、プロダクトオーナー、デザイナー
Web API担当者、iOSエンジニアで構成されていて

Web APIとの付き合い方を物語形式で説明。。
なんだか、話を聞いてあるあるネタが披露され
かなり、プレゼンが面白かったです。

まとめとして、
  • Web APIの知識は必須。
  • 文句を言うのは簡単、改善案を提案できる力を
  • Web API The Good Partsを読もう!

面白法人カヤック布田隆介さん『まだiOSでリッチな演出に疲弊してるの?』

面白法人って名前がインパクトのあるカヤックさん
CoreAnimationやUnity、cocos2dやライブラリで
演出を実装すると、それぞれにデメリットがあり疲弊する

そこで、何か別な方法がないかと探したところ
iOS標準のSpriteKitを利用して演出を作成それをUIKitで利用

エディターでのパーティクルの作成
SKActionでパーティクルにアニメーションをつけれる

UIKitと一緒に使う場合の注意点としては
UIViewの上に透明なSKViewを乗せ
SKViewのタッチイベントを無効にする。
UIViewの[0,0]とSKViewの[0,0]の座標が違うので変換を行う等
具体的なテクニックが紹介されました。

最後にまとめとして
  • Appleが提供しているので安心
  • 既存のコードの邪魔をすることなく導入できる
  • デザイナーさんも使える
UIKitとSpriteKitの組み合わせはありで
リッチな演出もiOSネイティヴでとまとめられました。

そのあと、ベストプレゼンターを投票、懇親会で発表がありました。
ベストプレゼンターはWantedly incの杉上さん。。
懇親会では、ぐだぐだ喋りながら過ごしてしまい。写真を撮り忘れていました。。orz..