watari開発 – Advent201924 –
stage24: 画像をtwitterに上げる
ようやくここまできた。ときはすでにクリスマスイブ。さっそく実装を進めていこう。
swifterに連携する
これまでの実装でほとんどパーツは揃っているはず。投稿すべき画像は手元にあり、コード上で扱うことができ、twitterへ投稿するためのライブラリも導入済み。ということでswifterを使って投稿する改修を入れる。
// ImageView
+import Prephirences
+import SwifteriOS
+import Keys
...
+ let keychain = KeychainPreferences.sharedInstance
+ let watariKeys: WatariKeys = WatariKeys()
...
+ if let credential = self.keychain.dictionary(forKey: "twitter"),
+ let oauthToken = credential["accessToken"] as? String,
+ let oauthTokenSecret = credential["secret"] as? String {
+ let swifter = Swifter(consumerKey: self.watariKeys.tWITTER_CONSUMER_KEY,
+ consumerSecret: self.watariKeys.tWITTER_CONSUMER_SECRET,
+ oauthToken: oauthToken,
+ oauthTokenSecret: oauthTokenSecret)
+ swifter.postTweet(status: "テスト投稿 from アドベントカレンダー", media: image.pngData()!, success: { _ in
+ print("succeeded.")
+ }, failure: { error in
+ print("failed.")
+ print(error)
+ })
+ }実装本体はsave imageのところに入れる。
実行！
してみたところ。
SwifterError(message: "HTTP Status 413: Payload Too Large, Response とのこと。
調べてみると、
https://developer.twitter.com/en/docs/media/upload-media/uploading-media/media-best-practices
にある通り Image size <= 5 MB, animated GIF size <= 15 MB なので5MB以下じゃないといけないらしい。リサイズしないと。
リサイズ
let canvas = CGSize(width: 300, height: CGFloat(ceil(300/image.size.width * image.size.height)))
let resized = UIGraphicsImageRenderer(size: canvas, format: image.imageRendererFormat).image {
_ in image.draw(in: CGRect(origin: .zero, size: canvas))
}これで大丈夫なはず。（適当に300pxに縮小）
結果
post部分を以下のように修正して、
swifter.postTweet(status: "テスト投稿 from アドベントカレンダー", media: resized.pngData()!, success: { _ in
print("succeeded.")
}, failure: { error in
print("failed.")
print(error)
})実行すると
https://twitter.com/toriumi0118/status/1209124126993965057
まとめ
明日は少し作りながら思うところもあったのでそちらを書くことにするため、今日は作ったもののまとめをしていこう。
今回のテーマは「プロダクト開発」だった
課題感の模索、課題の選択と集中、解決した状態の妄想、解決策の構想、実現方法の選定、機能リストのリストアップ、目標数値の決定、環境構築、実装、開発環境整備
を行ってきた。
企業だともっと複雑なフローになるだろうし、一つ一つに様々なレイヤーの人が参加していて意思決定も一朝一夕というわけにはいかない。それぞれ考える軸が異なるし、頭の切り替えも必要だ。得意不得意もある。
プロダクトを作り切るということ
今回は「自分の課題（っぽいもの）」を解決するために実装に着手した。当初は全然間に合うであろうと未来の自分に期待していたのが、そんなこともなく旅行先にも全く間に合わず・・・ではあったが、やはり継続して開発するというのは必要なことだ。千里の道も一歩から。ぜんぜん未達だけど自分の問題が解決する製品が完成するまで地道にこのプロダクトをコーディングしていくしかない。
プロダクトを作りきるというのはとてもカロリーを使うことで、自分が諦めた時がプロダクトの終了する時になる。一方で、どこまで作ればいいのか分からない、いつリリースすればいいのかも悩ましい。どこまで作ったら出せばいいのか。そんな悩みとも戦いながら少しずつでも作り上げていくための自分への発破の意味でアドベントカレンダーとした。
+アルファで必要なこと
今回話が全然できなかった内容としては、コードのクオリティとかデザイン、またマーケティング（伝える）の部分がある。サービスやプロダクトのリリース基準にはクオリティとデザインが、サービスを開発したあとはすぐにマーケティングが大きく関わってくることになるが、今回はそこまで至らなかったために特に話はしていない。ではあるがある程度以下のような話になっていくかと思う。
クオリティとデザイン
プロダクトやサービスの特性は大きく以下のような優先度になる。
機能 > デザイン > ストーリー
上位を満たせば下位のものは後からでもいい。みたいな理解をしている。要するにこの世に一つしかない機能であれば全然ダメなデザインでも、全くストーリーがなくても使ってくれる人は現れるだろう。
しかし昨今は、機能的な優位性は速攻で真似される時代になっているため、どのプロダクトもきれいな見た目（デザインをしている）ことが多い。また、macが出てきてからパソコンはどれも同じような見た目になった。SNSだってsnapchatが流行ってfacebook storyが出てきて、顔を加工するカメラだって無限にある。これくらいまでになると機能的な優位性はほぼ差異はなく、デザインはどれも綺麗で、、、となる。すると「自分が、チームが、企業が、何を想って作っているのか」が大切な要因になる。
私は判断が01になりがちではあるが、この辺りはバランスで、現状のwatariはまったく機能がない。のでまずは主機能を作る。それでまぁ適当なデザインを付けて一度出す。のが目標である。もちろん01ではないので、実装しながらもデザインの概要を考えたり、自分はなぜこんな毎日コードを書いてるのかを自問しながらストーリーを掘り下げる。
今回のアドベントカレンダーでは機能実装重視だったので
- textの投稿機能
- 画像の投稿機能
- twitter連携
が出来上がったところだ。まだ全然機能的には足りていない。が、あとはwebサイトを作ってデータを連携して記事になるようにしてみようと思う。
本質的な痛みの発見・解決まではまだまだ道は長い（と思う）。しかし、自分のサービスを自分で構築して回していければとても楽しいことではないか。とも思っているので、やりながら考えながら進めていければ良い。
マーケティング
全然専門ではないので、どうしようかなと思っている部分ではある。
先日読んだ本にわかりやすく載っていたので噛み砕くと、サービスには「集客、接客、増客」というのがある。マーケティングは「集客」に当たる。こと、アプリやサービスだとデザインをどうするとか機能をどうするとかの話になりがちだが、これらは全て「接客」部分だ。路地裏にカフェをオープンしたら一番にやることは駅前でビラ配りだろう？アプリも同じだ。
ということで、きっと出来上がったら誰かに使ってもらうように頼んだり、プレス出したり、勉強会で発表したりしていくのが良いのかなぁ。投稿にサービスのURLを含めるというのもありかもしれない。
その時がきたら考えよう。
次回は
クリスマスらしい話をして締めとしよう。
- 前の記事
watari開発 – Advent201923 – 2019.12.23
- 次の記事
watari開発 – Advent201925 – Merry Christmas! 2019.12.25