Vue.jsアーキテクチャリング勉強会でVue のアーキテクチャ のLTをした話

 

10月30日にクラウドワークスで「Vue × Vuex のアーキテクチャ完全に理解した」というタイトルで登壇させていただきました

 

cw-engineers.connpass.com

 

 

 

登壇のきっかけ

今回、サービスでVue.js Nuxtの環境で開発を行ったので、その知見をまとめたいと思っていた際にみーたさんのTweetを見て、これでLT駆動開発だっ！と思い申し込みました。

 

 

 

登壇前の準備

実際に今回開発を行ったメンバーは僕だけじゃないので、登壇前に社内で内容を話あって決めました。

最後の方にめちゃくちゃ追加しましたが...😇😇😇

開発の内容を振り返りしてまとめた感じなので、完璧な資料とはいかないですが、開発に臨む前に見るには良い内容になったかなとは思います。

 

当日

めちゃくちゃ緊張しながらいきました！

何回かLTは実施していましたが、20分ものLTはあまりやったことがなかったので...

様子をツイートと共に振り返りたいと思います。

 

一番最初が一番楽

 

わかりみ

 

なるほどと思いながら聞いてました。

 

完全に理解した()

 

element uiはいいぞ〜

 

この辺の議論は面白かったのでアンケートとった(後ほど)

 

型安全で開発したい(切実)

 

もちろんこういう使い方もあるので、あくまで大規模の時はって話である

 

今度見る！

 

これどっちが良いのよ

 

これが言いたかった

 

うれぴい

 

宣伝をした

 

Organismsの割合が思ったより多かった。確かにPagesだけだとemit地獄になったりしてつらみが深いし、propsで渡すのもめんどくさいけどね。

 

登壇後

なんとはてブのTOPにでてた...

ちょっといやかなり恐縮である。。。

SpeakerDockに乗せた資料も5kを超えていたので、はわわわわわってなりました。

 

 

 

次の目標 

資料内でも言及していますが、型が欲しいっ... と思いながら開発していたので、型導入したときにまたどこかで話をしたいなと思ってはいます。

 

 

また、資料は完全ではないので、何か質問や議論やこう思います見たいな話がありましたら、是非是非TwitterのDMなどで連絡いただけるとありがたいですー！！！🤗🤗🤗

 

 

 

 

 

iOSDCに行ったことない人も参加を味わえるブログというのは言い過ぎている


そう。言い過ぎている

 f:id:entaku19890818:20190916194133j:plain

iOSDC Japan 2019はiOSやその他諸々を題材としたLTが多いカンファレンスです。

iosdc.jp

 

今回は初日は体調が悪くいけなかったので2日目から、、（2日目も途中から）

 

 

 

画像処理における、UIImageとCGImageとCIImageの効果的な使い分け

 

speakerdeck.com

 

画像処理のお話。

CIImageは恥ずかしながら知らなかった..

 

スライドの資料が丁寧ーーーーー！

f:id:entaku19890818:20190916151117p:plain

 

結果から言うとCIImageが早かったと言う内容でした。

実験をするのがとても良いですよね。普段このような実験に時間取りずらいので。

 

 

 

www.slideshare.net

 

節子の人。

応援したった。

 

せやなみが深い。

分離がされていない状態ではそもそもテストができない

 

 

いい言葉。

 

 

全体的に業務よりの話だったと思う。

「チームとしてどういう痛みを許容するのかちゃんと共有して決断しようね」

という話だった。

個人開発でもない限りエンジニア一人で決断て言う状況は存在しなくて、ちゃんと恐れず巻き込まないとダメ。言うは易く行うは難し。

 

 

ソーシャルライブサービスにおけるデジタル化粧の仕組みと実装/iOSDC19

 

speakerdeck.com

 

noppeさん

 

デジタル化粧とか難しそうな印象でしたね

 

photoshopで輪郭をｼｭﾂとする方法を学べるらしい

 

はい。

 

今回出演した部分は全てOSS作ってるそうです。sugoi

 

深掘りしたらめちゃくちゃ難しいんでしょうが、僕でもできるかもと思わせてくれそうな内容でよかったです。難しい内容から初歩でも動かせる内容に切り取るの素晴らしいと思いました。

 

 

LTでは友達が出てたので応援してました。

 

 

 

2日目の茶会は出られませんでしたが、最終日の懇親会は参加しました。

人見知りの割にはまぁまぁ喋れた。

 

f:id:entaku19890818:20190916194059j:plain

 

 

 

 

 

発表者みんな楽しそうですごく良かった。

今回僕もプロポーザル出してたが、一つもかすらなかった。。。

この悔しさは忘れたくない！

 

そういえばリジェクトコンってやつに応募してたきが。。。

（今から頑張る）

 

iosdc-reject-conference.connpass.com

iosdc-reject-conference.connpass.com

 

KotlinFestに行ったことない人も参加を味わえるブログ

 

KotlinFestとは「Kotlinを愛でる」をビジョンにKotlinファンが集まる技術カンファレンスです！

今回は2019/08/24（土）に開催されました。

 

 

こちらが公式Connpass

kotlin.connpass.com

 

 

 品川で開催。駅から該当の3階までいくとわかる。

 

名前書いてバックもらった

 

スケジュール

f:id:entaku19890818:20190825113217j:plain

 

 

以下参加したセッションについて

 

オープニング・セッション

 

いえーい！

 

あと、JetBrainsの中の人が講演してました。

twitter.com

 

JetBrainsはMPP推しらしい。（初めて知ったけど）

要は全部Kotlinで書いて行こうぜって感じ。

去年のKotlinConfでも同じことを言ってたらしい。


KotlinConf 2018 - Effective Multiplatform Kotlin Development by Marcin Moskala

 

 

 

 

 

お昼休憩後、セッション開始。見たもののみ記載

 

資料全体まとめはスタッフのさわらさんがまとめているよ☺️

 

Kotlin コルーチンを 理解しよう 2019

八木俊広さん ( @sys1yagi )

 

speakerdeck.com

 

 

直前までブースの人と喋っていてサテライト勢となるぼく（右上奥）

 

 

 

この人が論文内でコルーチンのことを初めて書いたらしい。（原文見つからず）

メルヴィン・コンウェイ - Wikipedia

 

Swiftでやったことあるから多少理解したつもりになれる

 

実践的な内容ありがたき

 

図があったほうがわかりやすい

 

テストもわかった

 

つまりこうなる

Coroutinesから紐解くKtorの仕組み

小谷野 雄史さん ( @bandwagondagon )

※資料が見つからなかったので見つけ次第更新予定

 

Ktorの話、「けーたー」っていうらしいよ

 

Ktorはパイプラインの中にフェーズを持っててそこでCoroutinesを使ってるらしいよ

f:id:entaku19890818:20190825115912p:plain


suspend関数を駆使してるらしいが挙動がわからん

 

そして無事こうなる

 

 

フロントエンドもKotlinで書きたい！ -WebページをKotlin/JSで作った軌跡-

Subroh Nishikoriさん ( @subroh_0508 )

 

speakerdeck.com

 

肩にいる人には触れないスタイル

 

KotlinでReactやるときにはこれ

 

実は彼の発表は前も聞いていたので、なんとなくわかってたけど改めてdivタグKotlinで書くのすごいなって思いました(小並)

f:id:entaku19890818:20190825121112p:plain

 

資料内にも出てくるがKotlinでjsやHTML構造がかける一方で、やはりUIフレームワークを使えないと有用でないため、Material-UIのラッパーを作ったらしい

 

なおどうしてもKotlinで表現できない場合、Kotlin内でjsを書ける模様

 

ポートフォリオ作る欲。アがるな

 

Kotlin/Nativeはなぜ動くのか？

荻野陽太さん ( @youta1119 )
https://speakerdeck.com/youta1119/kotlinfest2019

 

speakerdeck.com

 

Kotlin / Nativeの内訳

 

当然こうなる

 

 

正直最後のセッションは全く知識が無くわからなかった😞

 

クロージング

 

他のコミュニティの宣伝もできるよ！！！

f:id:entaku19890818:20190825122415j:plain


 

懇親会

 

懇親会ではKotlinだけでなく様々な言語で開発している人がいた。

学生もいた。（参加費無料でうらやま）

懇親会中にも言ったが、Swiftのイベントと違ってKotlinのイベントはサーバーサイド/フロント/アプリ開発と本当に幅広いのは特徴でJetBrainsの「全部Kotlinで書こうぜ」な世界に本当になっちゃうかもなーと思いながら喋っていた。

 

それは今回のセッションにも表れていて、サーバーサイド/フロント/アプリ全てのセッションが聴けたのはよかった😊

開発欲アガった🤩🤩🤩🤩🤩🤩

 

 

 

そして、これを書いているときに大事なことに気がつく。

 

 

最後に

 

 

本日はご参加ありがとうございましたーーーー！！

 

 

 

 

Swift/Kotlin愛好会合宿(7/6-7)に初参加してきたが最高だったことを参加者目線で話そうか!!!!!

 

どうもentakuです。

 

さぁSwift/Kotlin愛好会合宿を終わらせましょうか。

f:id:entaku19890818:20190709082558p:plain

 

 

運営メンバーの素晴らしいブログたちはこちら。

当日の流れはこちらを見た方がいい。

 

afroscript.hatenablog.jp

 

blog.maripara.org

 

今回僕は完全なる参加者目線で書きます。

 

 

 参加の動機

 

私は何度かSwift/Kotlin愛好会に参加/LTも1-2回程度登壇させていただきました。

今回はずっと作りたいと思っていたスポーツ観戦系個人アプリを集中して作りたいと思い参加しました。

初参加とはいいましたが、運営メンバーの人と技術書典も出したりと顔見知りは多い方だったと思うので、他のメンバーより比較的リラックスして望めたかと思います。

 

 

 

実際どうだったか？

　Twitterのハッシュタグ はとても騒がしく見えますが、現地はとても静かでした。

　それぞれ盛り上がったり、集中したい人は集中するといった感じでとても良かったですね。

 

 

twitter.com

 

 

合宿の最後には談義タイムほぼ全員が談義したのではないでしょうか？

皆さんの特色が出てるLTで良かったですね😊

 

誰かに見せようと思えるから頑張れるんだよなぁ

 

f:id:entaku19890818:20190709084438p:plain

 

 

f:id:entaku19890818:20190709084421p:plain


 

 

> んで？肝心のアプリは？

 

作ったよ！

とりあえず動くよ！

改善点が死ぬほどありますが、この合宿で作ったのが最初の思い出になりますよう。

github.com

f:id:entaku19890818:20190709084821p:plain

 

 

 

 

Togetterが楽しすぎて永遠に見てられるな...

 

togetter.com

 

 

また進捗するぞ！

 

Tweetで振り返るKotlin愛好会LT

 

おはようございますentakuです。

 

4/25にKotlin愛好会にLT枠「iOSエンジニアはイケてるAndroid開発 を完全に理解した()」で参加したので、Tweetと共に振り返ります。

 

love-kotlin.connpass.com

 

資料はこちら

speakerdeck.com

 

（改めて読むと恥ずかしいな）

 

 

会場みなさんとの距離が近めでよかった

 

ああ、そうですね。

この辺はちゃんと定義しないと難しいですが、

「意図した責務分けがなされていて、サクサクできる開発」ですかね

 

それな

 

 

Sample おとして実行するだけでもだいぶ勉強になる気がする

github.com

 

 

 なんとなく理解できてるつもりでもなかなか難しいんですよね。

動かしながら感覚掴まないと。

 

神

 

 

マッピングの表は自分でも説明しながら思いましたね()

iOS/Android でViewの差分があるのは当たり前なので、その辺は異なるものとして認識しないと僕のようになる。

 

 

 

とてもいい。

僕の発表が貢献できてたら嬉しいです( ´∀｀)

 

github.com

 

機能追加はよ！

 

 

 

 

 

技術書典でSwift/Kotlin愛好会の合同執筆本を出典した話

 

こんにちはentakuです。

2019/4/14(日) に開催された技術書典に初執筆初参加しました！

熱がまだあるうちにブログにまとめます。 

 

こんな立派な本の一章かけるなんてありがたい...

 

 

 

執筆することになったきっかけ 

Swift/Kotlin愛好会主催者の @jollyjoester さんのツイートがきっかけでした。

 

Hideyuki Nanashima on Twitter: "Swift/Kotlin愛好会で #技術書典 ６申し込んだぞ！ https://t.co/MYsRTRZJl6"

f:id:entaku19890818:20190415071526p:plain

きっかけ

「技術書典」という名前を聞いたことはあったんですが、正直どういうイベントか詳しく分かってなかったです()

しかし、1年以上iOS開発してきた経験をまとめるものが欲しいと思うで参加しました。

 

Re:VIEWで執筆

執筆は「Re:VIEW」という書籍執筆支援システムを使うのが一般的だそうです。

(本当はカスタム版を使ったんですが、リンク忘れた😇)

reviewml.org

 

書き方はMarkDownのような感じで、

書籍用のテンプレートファイルを見ながら編集したり、どんな表記がいいか「Re:VIEW XX 」などでググって執筆しました。

f:id:entaku19890818:20190415072728p:plain

VSCodeでRe:VIEWのテンプレートを執筆

 

普段技術ブログを書いている方には内容は困らないかも知れませんが、「本という物理媒体に残ってしまう..」というプレッシャーを感じながらの執筆はまた違ったものだと思います。

 

 

それでも、ものが出来るのはやはり楽しいもので、作りながらみんなでワイワイするのは楽しかったです。

f:id:entaku19890818:20190415073527p:plain

PDF生成してテンション上がる

 

 

執筆内容への思い

「サクッとお天気iOSアプリを作ってiOSエンジニアになる！」という内容で書かせていただきました。

僕はiOSアプリ開発者として働く中で、「0->1でiOSアプリを作る」という経験が重要だと考えています。

細部の機能やデザインの追加/変更/削除は全体を理解していなくても可能ですが、全体を把握できないと突貫工事になってしまいどこかに無理が生じてしまいます。

最小構成で作成し、意図して機能やデザインの追加/変更/削除をしていくことが自分が開発するアプリを成長させていくために必要なことだと考えているため、今回はこちらの内容で執筆させていただきました。

 

いざ当日

すごい人..すごい人..

正直こんなに人がいっぱいいるイベントだと思ってなかった...

 

f:id:entaku19890818:20190415080449j:plain

 

 

 

印刷した本は技術書典の会場に直接届けるので、著者とはいえ手に取れるのは当日です。

 

f:id:entaku19890818:20190415080428j:plain

 

 

150部作成しましたが、完売。本当に嬉しいですありがたいです。

 

f:id:entaku19890818:20190415080734j:plain

 

 

振り返り

以上駆け足でしたが、技術書典でSwift/Kotlin愛好会の合同執筆本を出典した話でした。

今回実際書いてみて、一番感じたことは普段から小出し小出しで書いていないと一気にまとめるのは難しいなということです。

少しでも疑問に思ったこと、解決したことはなんらかの形で出していって結果本になるくらいの気持ちが一番望ましいですね。

 

 

 

techbookfest.org

 

 

 

 

 

try!swift workshop 'Testing and Performance Workshop'

 

try!swift 3日目のworkshopの一つである'Testing and Performance Workshop'に参加して来ました。

 

www.tryswift.co

 

会場はこちらでした。

www.google.co.jp

 

講師のSamuelさんがワークショップ用のリポジトリを作ってくれました。

github.com

 

パフォーマンスに問題のあるプロジェクトを直していこう！と言うものです。主に実施した2つを紹介していきます。

  1. ScrollingSmooth
  2. ImagesInTables

 

  1. ScrollingSmooth

※すでにmasterの最新は解決ずみのものが上がってますのでご注意ください

Initial commit with sample projects. · sgoodwin/PerformanceDemos@92fcf1e · GitHub

 

  • 問題発見

これを実行すると...真っ白😮

f:id:entaku19890818:20190323171330p:plain

これを調査します。

 

  • 調査

XcodeのメニューからProduct>Profileを開き"Time Profiler"を開きます

f:id:entaku19890818:20190323171656p:plain

 

すると....

f:id:entaku19890818:20190323171907p:plain

CPU100%😇

 

 

お気付きの方も多いかも知れませんが、10,000,000回appendしており、また全てメインスレッドで行なっているので、描画処理が進まないと言う状態です。

    override func viewDidLoad() {

        super.viewDidLoad()

        

        for _ in 0..<10_000_000 {

            data.append(randomWord())

        }

        tableView.reloadData()

    }

 

 

  • 解決

そこでswiftでの非同期処理を実現するために"DispatchQueue"を使います。

    override func viewDidLoad() {

        super.viewDidLoad()

        

        namesQueue.async { [weak self] in

            guard let self = self else { return }

            for _ in 0..<10_000_000 {

                self.semaphore.wait()

                self.data.append(self.randomWord())

                self.semaphore.signal()

            }

        }

        DispatchQueue.main.async {

            self.tableView.reloadData()

        }

    }

 

viewControllerの全体はこちらから

PerformanceDemos/ViewController.swift at master · sgoodwin/PerformanceDemos · GitHub

 

結果

f:id:entaku19890818:20190323175939p:plain

 

 

Time Profilerで見るとメインスレッドが空き、サブスレッドが張り付いていることがわかります。

非同期処理を行うことで「時間のかかる処理は別の場所で実行する」と言うことが可能になります。

f:id:entaku19890818:20190323180006p:plain

 

2.ImagesInTables

 

続いて名前から察してるかも知れませんがimageの読み込みです。

実行すると...カクカク😱

f:id:entaku19890818:20190323181733g:plain

 

  • 調査

CPU上ではさっきと違って100%と言うわけではありません。

f:id:entaku19890818:20190323182118p:plain

 

ですが、コードを見るとセルの表示時にURLからデータを読み込んで、表示しています...

  • URL先のdataを取る
  • とったdataをUIImage型へ変換し、imageViewへ設定する

ということを行うので、メインスレッドが混雑してカクカクになってると思われます。

 

    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {

        let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath)

        cell.imageView?.image = UIImage(data: try! Data(contentsOf: URL(string: "https://via.placeholder.com/150.png?text=Demo+desu!")!))

 

        cell.textLabel?.text = "row \(indexPath.row)"

        

        return cell

    }

  • 解決

またもや" DispatchQueue"さんですよ。

今回はちょっと工夫してデフォルトイメージを設定してみました。

    let defautImage:UIImage = UIImage(data: try! Data(contentsOf: URL(string: "https://via.placeholder.com/150.png?text=Demo+desu!")!))!

 

    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {

        let queue = DispatchQueue.global(qos: .default)

        let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath)

        cell.imageView?.image = defautImage

        queue.async {

            let data:UIImage = UIImage(data: try! Data(contentsOf: URL(string: "https://pbs.twimg.com/profile_images/828386643560181761/zVBAD623_400x400.png")!))!

            DispatchQueue.main.async {

                cell.imageView?.image = data

            }

        }

        

        cell.textLabel?.text = "row \(indexPath.row)"

        

        return cell

    }

 

結果

f:id:entaku19890818:20190323183245g:plain

サクサク😻

 

ほんとは画像キャッシュとかすると思いますが、時間がなかった（メンドくさい）ので解決です。

 

 

 

Time Profilerを見るとcellごとにスレッドできてますね。

（これはこれでいいのだろうか？）

f:id:entaku19890818:20190323183820p:plain

 

 

画像読み込み周りはいつもライブラリに依存してしまっているので、仕組みがわかってないと困った時に解決策を考えられないなぁと感じました。

 

 

 

その他画面遷移で画面が重なりすぎないようにするお話と、UnitTestをやったのですが、そこまで行かなかったので、このブログはここでおしまいです😃

 

 

まとめ

  • 重い処理はサブスレッドを駆使し、UIを更新するメインスレッドは空けておくような工夫をする
  • 画像取得とキャッシュをよろしくやってくれるライブラリは神。先人に感謝。
  • 自分のプロジェクトでTime Profiler開こう！どのくらい重い処理をしているのかしろう

 

 

以上です。みなさんも試してみてください！🤗