Enigmo 開発合宿2019 in 湯河原

22 April 2019 by Sho Ito

こんにちは。気が付けば入社から一年が経ち、
新卒の肩書きを失った@sean0628_i です。

4月4日(木)、4月5日(金)の日程で開発合宿を行ってきました。
場所は前回と同じく、おんやど恵さんにお邪魔しました。

前回の開発合宿が2017年だったようなので、2年ぶりの開催ですね。

テーマ

今回は『チーム力のアップ』をテーマに設定しました。

前回は個人個人好きなことを行うスタイルだったようですが、
今回はテーマが『チーム力のアップ』でしたので、基本的にはチーム開発で取り組むことにしました。

参加者の希望を聞き入れつつ、実行委員が1-3人のチームに分けました。
そして、チームごと取り組む内容を決定し、合宿に臨みました。
合宿一ヶ月ほど前にチームを発表し、準備期間も設けました。

スケジュール感:
– 3月初 – チーム発表
– 3月中 – 内容決定・下準備
– 4月4日、5日 – 合宿開催

合宿でやったこと

内容に関しては、業務に関する範囲であれば基本的になんでもOK です。
最終的にそれぞれ以下の内容に取り組んでいました。

内容:
– 1班:STYLE HAUS フロントの性能改善(画像リサイズ)
– 2班:BUYMA フロントの性能改善
– 3班:商品画像分類
– 4班:STYLE HAUS タグのサジェスト
– 5班:Jenkins のデプロイジョブのGitLab-CI 化
– 6班:GitLab Runner Autoscale on AWS

当日の様子

東京駅出発


皆さん遅れてくるかなぁと思い15分前集合にしましたが、まさかの全員5分前行動。
出発の20分前には全員集まりました、、、さすがです!!!

開発開始


湯河原駅周辺で昼食をとって、開発開始です。
テーブルはチームごとです。


キーボード作成が趣味のメンバーは、自作キーボード持参で合宿に臨んでいました。


BUYMA パーカーを着て開発するメンバーも!

夕食

夜は宴会!!!
テンションの上がったメンバーがコスプレをし、晩酌をしていると、、、
密告され、部長殿におこられてしまいました。。。

宴会の後は反省して、黙々と開発に励んでおりました。。。

記念撮影


宿の前でパシャり。
2日目はお昼まで開発を行い、湯河原駅周辺で昼食を食べ帰路につきました。

まとめ

当日は大きく成果を出せたチーム、あまり成果を出せなかったチームとありました。
ただ、事前準備の期間をおよそ1ヶ月用意したこともあり、どのチームも最低限の成果は出せていたように思います。

また、通常の業務を離れて普段あまり関わることのないメンバーと開発を行うことができて、
参加者それぞれ新たな気づきがあったことと思います。

『チーム力のアップ』という点で見ても、縦・横両方の意味で向上することができました。

私個人としても一日中シニアエンジニアの方に手取り足取り教えていただき、
Serverless、Docker などの知識を深めることができました。

またとない貴重な時間を過ごさせていただきました。

今後も積極的に社内勉強会、開発合宿を開催していきたいと思います。

最後まで読んでいただきありがとうございます。

Pocket

Leave a comment | Categories: Events, Organization | Tags:

iOSアプリのデザインをしてみて

07 March 2019 by hanzawa

はじめまして。BUYMAのiOSアプリチームでデザインを担当しています。
この記事を読んでくださりありがとうございます。

2019年2月に、お問い合わせ機能をネイティブ化しました。
より使いやすくするために、Webviewからネイティブ化し、あわせてリデザインすることになりました。

Webとアプリを作業する上で、デザイナーとして苦労した部分を、新しいデザインと一緒に書いていきたいと思います。

 

まず、BUYMAのiOSアプリってどんな感じ?

 

BUYMAはショッピングサービスなので必要なページがたくさん。

現状、アプリの半分くらいが、Webviewです。

ネイティブ化されたページとWebviewのページが混在しているため、ページによってデザインテイストが異なっていることを課題のひとつとして感じています。
ユーザーがアプリを起動してから目的を達成するまで、気持ちよく使えるよう統一されたデザインにしていきたいと考えています。

 

実際にデザインするときに考えていること2つ

 

1・デザインのトレンドを押さえたユーザーインターフェース

古っぽいデザインは、扱っているコンテンツさえ古く感じさせてしまうのでもったいないです。特にBUYMAでは、日本未入荷のレアアイテムを揃えていたり、最新のトレンドを発信しているサービスのため、サービスブランディングの観点からも、とても大事になってくるポイントだと考えています。

そのためまずはとにかく他社リサーチに時間をかけています。国内外の人気アプリのデザインをチェックしてよく使われているUIを参考にしたり、海外のデザインギャラリーを漁ってアイディアの引き出しを増やしています。

よく参考にしている海外デザインサイト

2・ユーザーが目的を達成するためのデザイン

トレンドだけ追いかけて「とりあえず流行りのデザインを取り入れたけど、実は使いにくかった」となっては本末転倒です。そのため、ユーザーが目的を達成しやすいデザインかどうか、という視点が重要になってきます。

そのページではユーザーに何を達成してほしいのかを明確にすること、そしてそれを達成するためには、ユーザーにどういうアクションをしてほしくて、きちんとアクションしやすいデザインになっているか、ということを考えながらデザインを行っています。

 

お問い合わせ画面の目的

 

BUYMAはCtoCサービスです。注文がはいるとパーソナルショッパーが買い付けに行き、商品を送ってくれるサービスです。
商品によって、配送日数が異なっていたり、買い付けに行ったけど在庫が無かったというケースが発生する場合があります。

もしユーザーがBUYMAを、在庫を持つ一般的なECサイトだと思って使っていた場合、「想定よりも配送日数が長かった」「注文したのにキャンセルされた」といった体験はユーザーのペインポイントになりかねません。

このペインポイントは注文前に商品について事前問い合わせをすることで解消できます。
お問い合わせ画面では、このようなペインポイントを解消することを目的とし、2点を達成することが必要だと考えました。

  1. BUYMAはCtoCサービスだと伝えられていること
  2. パーソナルショッパーへ在庫や商品詳細についてお問い合わせがしやすいデザインであること

 

現状のお問い合わせ画面の課題

 

それでは本当にCtoCサービスということが伝えられているのか、お問い合わせがしやすいデザインになっているのかということを念頭におき、現在のデザインから改善できるポイントがないかを考えていきます。

▼現状のデザイン

▼現状の課題

  • CtoCサービスということが伝えられているのか

→ 1 パーソナルショッパーへの問い合わせフォームだということが伝わりづらいため、CtoC感がなくハードルが高い印象を与えかねない。

  • お問い合わせがしやすいデザインになっているのか

→ 2 商品ページからお問い合わせボタンをもっとタップしてもらいたいので、現状よりもボタンに気づきやすくしたい。

→ 3 お問い合わせ一覧ページは、なんのアクションをしてほしいページなのか分かりづらい。

以上の課題に対してリデザインしていきます。

 

課題に対するアプローチ

 

▼改修後のデザイン

▼課題に対する変更点

1 ・CtoC感がなくハードルが高い印象を与える。

  • メッセンジャーアプリに寄せたUIで問い合わせのハードルを下げ、気軽さを出しました。チャット形式のUIは、サイトへの問い合わせではなく、パーソナルショッパーとの人対人のコミュニケーションであることを意識づけられたと思います。
  • パーソナルショッパーのアイコンをナビゲーションバーの右位置に表示し、常に目に入るようにして、パーソナルショッパーの存在感を出しました。アイコンをタップすると、パーソナルショッパーページや出品アイテム一覧を見ることができます。
  • 他人のお問い合わせ内容を見やすくしました。改修前はお問い合わせ内容がトグルに包まれて一文しか出ていなかったものを、全文出してひとめでわかるようにしました。他人のお問い合わせ内容が目に入ることで、BUYMAはCtoCサービスであり、在庫確認などの問い合わせが必要であることを伝えられたのではないかと考えています。

 

2 ・商品ページのお問い合わせボタンをもっとタップさせたい。

  • 商品ページのお問い合わせボタンの領域を広め、件数を表に出すことで、他の人の活発なお問い合わせのやりとりに気づきやすくなるようにしました。結果、問い合わせボタンのタップ数を130%増やすことができました。

 

3 ・お問い合わせ一覧ページは、なんのアクションをしてほしいページなのか分かりづらい。

  • 新規問い合わせボタンをアイコン化して視覚的に認知しやすいようにしました。また、スクロールしてもボタンを画面右下のポジションでフィックスさせることで、ユーザーがどのタイミングでも問い合わせフォームへ進めるようにしました。
  • 新規問い合わせボタンと同レベルで目立っていた「指名リクエスト(※)」のボタンの優先順位を下げて奥へ場所を変更しました。指名リクエストボタンの優先順位を下げたことで、クリック数は減りましたがリクエスト数に影響は無かったため、ページで誘導したいアクションをよりシンプルにできました。

※「指名リクエスト」とは、自分が探している商品を世界中にいるパーソナルショッパーにリクエストすることで自分の代わりに欲しい商品を探してもらうことができるサービスのこと。

 

Webデザインとアプリデザインの違い

 

Webページのデザインの場合はPhotoshopでデザインし、コーディングまで担当しますが、
アプリデザインに関してはSketchで作成したデザインをZeplinにエクスポートして、エンジニアに実装してもらっています。

ちなみに、Webデザインの頭でアプリデザインをしてもエンジニアからの手戻りが発生することが多いです。
わたしはWebとアプリの違いを理解しないまま、アプリのデザインをはじめてしまったので修正対応に苦労しました。

たとえば…

・このボタンを押したときのボタンの挙動は?アニメーション入れる?
・ここはページの遷移はモーダルなのか?プッシュなのか?
・可変要素で無いパターンの場合、高さを詰めるか?
・アラートやアクションビューの要不要
・タブバー隠すか出すか
・なんか実装してみたらここの動きがヘン

Webページのデザインでは考慮しないようなポイントのため、アプリのデザインをするときはアプリの仕様をおさえておくことが必要です。
わたしは、モーダルとプッシュの役割の違いから勉強しなおしました。

わたしが今回特にお世話になった記事はこちらです。
ユーザインターフェイスのデザインのヒント – Apple Developer
iOS ヒューマンインターフェースの原則
初心者がアプリのUXデザインで押さえておくべき9つの原則
[iOS版]アプリのUIデザイナーとして働き始める時に覚えておくと便利な用語

わたしと同じように、これからiOSのアプリデザインに挑戦するという人がいたら、ひとまずAppleのヒューマンインターフェースガイドラインは必読です。
アプリの仕組みを理解することで、エンジニアとの共通言語が増え、コミュニケーションもより円滑になります。

 

BUYMAのiOSアプリチーム

 

とこんな感じで、iOSエンジニアに助けてもらいながら、お問い合わせ画面を新しいデザインにすることができました。

Webデザインをするとき、HTMLやCSSのコーディングのことまで考えながらデザインしますが、
同じようにアプリデザインでもアプリエンジニアの実装のことも考慮してデザインできるデザイナーでありたいなと思います。

デザイナーだけでデザインをするというよりは、チームみんなで良いプロダクトになるよう日々ディスカッションしています。
BUYMAのiOSアプリチームのメンバー構成は、デザイナー・エンジニア・MDでアプリの改修やブラッシュアップをおこなっています。

わたしたちと一緒にiOSアプリをつくっていくメンバーを募集しています。
現在ディレクターが不在のため、特にディレクター職の応募をお待ちしています!

採用情報

Pocket

Leave a comment | Categories: Design

いまさら聞けない!?プロダクトマネージャー・ディレクターが機械学習の案件を始めるまで

25 December 2018 by matsunaga

はじめに

この記事はEnigmo Advent Calendar 2018の25日目です。

BUYMAでプロダクトマネージャー・ディレクターのようなことをしています。
機械学習に関する案件を初めて進めてみようと思い、 プロダクトマネージャー・ディレクター目線で 、やってきたことや学んだことをまとめます。

知識がなくてもプロジェクトや案件は進めれるとは思いますが、ある程度理解があることで、プロジェクトの幅も広がりますし、エンジニアとのコミュニケーションも円滑になりますし、 何より自分も楽しいです

また、もし機械学習に関して知見がない会社でプロジェクトを進めていく場合の参考になればと思います。

この記事の対象者

非エンジニアプロダクトマネージャー・ディレクター  向けの記事です。

  • プロジェクトや案件で機械学習を利用しようと検討しているがどうしたらよいかわからない
  • 自分で機械学習学びたい!せっかくなら、プロジェクトや案件にしたい!(自分はこのタイプです)
    という方向け。

対象ではない方

  • 技術的な話とかかわらない方
  • 既に機械学習を利用してプロジェクトを推進している方
  • 機械学習に関わるプログラミングを実施している方
  • エンジニアの方

全体の流れ

1.基本知識のインプット
2.実際にコーディングもやってみる
3.プロジェクト・案件にするまで

基本知識のインプット

ゼロからスタートする場合は、何から初めてよいのか?と悩むことも多いと思います。

一番最初にやってみた

まず参考にしたのが下記の記事
【保存版・初心者向け】独学でAIエンジニアになりたい人向けのオススメの勉強方法

網羅されていて、わかりやすいが、プロダクトマネージャー・ディレクターとしては、ここまではいらない。(実際にやってみて途中でいろいろ挫折。時間もかかる)

その中で、やってきたことをプロダクトマネージャー・ディレクター向けに書きます。
下記に出てくる記事や本を読めば、最低限は大丈夫ではないかなと思います。

STEP1:まず機械学習を知る

例に漏れずここから。流し読みでもかなり面白い。

人工知能は人間を超えるか (角川EPUB選書)

読み終わると

  • AIってなんかすごそうってなる
  • なんかすごくAIがわかった気持ちになれる
  • エンジニアが言っていることが何となくわかるようになる

STEP2 : Pythonを知る

実際にコーディングもやることを考えると、ディレクターでもPythonは必須です。
全く触れたことがなかったので、本当に簡単なところから。

ドットインストール

動画を通勤中や移動中に見る。理解しようとせず最初は、流し見でよいと思う。
3回ほど聞くと、なんとなくわかってくる。

終わると

  • 動画なら、なんでも良いと思う
  • Pythonがわかった気になれる
  • Pythonを書いてみたくなる
  • エンジニアの言っていることがわかるようになる

Python3入門ノート

非常にわかりやすかった。
エンジニアではないので、日々コーディングしないと言語は習得が難しいので、なんとなく理解する程度で、読み飛ばす。
その中でも、読んでおくとよさそうのは、 Part3の「Numpyの配列」
ただ、読んでもほぼ忘れる。

あと、読み進める中で気になるところは、写経して実際にコードを書いみると良い。
一番重要なのは、 あとから困ったときに調べるために使うこと 。

読み終わると
  • Pythonがかけて嬉しくなる
  • エンジニアの仲間に入れてた気がする

STEP3(+α):Courseraのmachine-learning

無料 でここまで使える学習ツールはすごい!

機械学習のロジック部分で、実際にはCourseraを全くやっていなくてもコーディングはできる。知っておくとパラメーターチューニングの意味を理解できる面白い。
通勤中などの移動中に聞ける。
英語できなくても、日本語も用意されているのでほぼ問題ない。

こういう記事からも力をもらいながら、完了。

Courseraのmachine-learning

学習を終えると
  • なんか機械学習の理論がわかった気になれる
  • ただ、本当にすぐに忘れる
  • アンドリュー先生(講師の先生)が優しすぎて好きになる

##実際にコーディングもやってみる

PandasとMachineLearning

KaggleのLearnがめちゃくちゃ良い。しかも 無料
英語だけれど、Google翻訳を使えばほぼ問題なく進められる。

機械学習を実際に行う際のベースとなる部分なので、これはやっておくことをおすすめする。ただ、使わないと忘れるので注意。

本を読みながら深掘りしてみる

pythonで始める機械学習 を読んで、気になるところは写経してみる。

実際のプロジェクトをする際は、機械学習のパラーメーターチューニングなどはディレクターには求められていないと思うので、1章から3章くらいまでやれば十分だと思う。

読み終わると
  • 機械学習のコードが書けて、嬉しくなる
  • なんか実際のデータでやってみたくなる

(補足)コーディングに利用するツール

自分で環境構築できる方はぜひそちらで。
環境構築ができない/しない方は、GoogleのColaboratoryでやるのがおすすめ。
これも無料で簡単なので、僕もこれを使いました。めっちゃ楽です。

プロジェクト・案件にするまで

はじめに

プロマネとして、機械学習プロジェクトを始めるならこれは必読書です。


仕事ではじめる機械学習

本書では、機械学習やデータ分析の道具をどのようにビジネスに生かしていけば良いのか、また不確実性が高いと言われている機械学習プロジェクトの進め方について 整理しています。
本書はもともと、機械学習の初学者向けに書いた文章からはじまりました。入門者のために書きはじ めたのですが、実際には理論を軽めにしたソフトウェアエンジニア向けの実践的なカタログのような形 になっています。 アルゴリズムの話などは他の書籍でも数多く取り上げられているので、本書ではプロジェクトのはじ め方や、システム構成、学習のためのリソースの収集方法など、読者が「実際どうするの?」と気にな るであろう点を中心にしています

とある通り、
プロジェクト始めたいけど、でどうするの?
ということが書いてありますので、実施にプロジェクトを進める方にはすごく学びが大きいかと思います。
実際に、「その作業必要?」のようなリソース判断をすることや、全体像を理解することで手戻りを少なくする一助にもなるかと思います。

この要約がわかりやすかったです。

読み終わると

  • 機械学習のプロジェクトは思っているよりも多くのことがあるのだと知る
  • 実際にプロジェクトをやってみたくなる

実際にやったこと

本書の中で重要だと思ったのは、機械学習を使うことを目的化しないということでした。
機械学習の本なのに、 別に機械学習を使う必要は必ずしもない  と書いてあり驚きました。

実際に案件化していくステップとしては、
1.ユーザーの課題を明確にする
2.機械学習を使わずに解決する方法を考える
3.どうしても必要な場合は機械学習を活用する
です。

機械学習の有無にかかわらず、 ユーザーの課題を明確にする ことからスタートして、 機械学習を解決策の一つ として持っておく感覚かと思います。

STEP1:ユーザー課題を明らかにする

プロジェクトを進めるにあたり、課題を明確化します。
実際に僕らが進めた場合は、経営陣やビジネスサイドの方と、

1.経営陣が認識している事業課題
2.現状現場が認識しているサービス課題
3.サービス以外にも、現場メンバーの作業に関する課題

など、様々なレイヤーでサービス課題/業務課題に関するディスカッションする機会を取りました。
課題を俯瞰して考えることで、課題理解も広がり、実際モチベーションも上がりました。

このステップを終えると
  • やっぱり〇〇はすごい解決したいよね〜(サービスの大きな課題)を再認識できます
  • 普段そんな作業をしてるのか。。。という現場のリアルを知れるます
  • 他の部署の人と仲良くなります
  • 実際にやる前提で話をするので、すごく楽しいです。

STEP2:課題の解決策を考えて、進める

初めて案件を進めるとなれば、どのように案件を進めるかが難しいかと思います。

はじめての機械学習関連のプロジェクトということもあり意識したのは、いかに ライトに着地させて一定の効果を出す かでした。

そのための課題設定と解決策を決めます。

本当は、これが理想。
ただ、簡単に見つからないですよね。。。

実際に進めていくなかで、最初の案件として一番しっくりきたのはこういう施策でした。

機械学習を取り入れる理由が明確にあり 、且つ工数も比較的小さいもの。
ここを見つけてプロジェクト化していくことで、進みやすくなるかと思います。

実は、ここで言う開発工数とは、機械学習の基盤を作成する工数は除いて考えています。
機械学習の運用基盤を作成するのは工数がもちろん高いので、

  • できるだけ使い回せるロジックにすること
  • 一度作成すれば、それほどアプリケーション開発の工数が変わらないこと

が重要なので、複数案件化できる状態にしておくことで基盤を作りやすくなるかと思います。

STEP3:巻き込む人を間違えない

前出のまとめ記事にもありましたが、案件を進める上で上記のメンバーは巻き込む必要があります。
そこで間違えると話が進まないので、初めてプロジェクトを進める場合は気にしてみてください。

まとめ/終わりに

ここまでお読みいただきありがとうございました。
はじめての記事でしたが、少しでも参考にしていただければ嬉しい限りです。

  • 基本的なインプットから、コーディング、プロジェクト化など一通りやってみて非常に勉強なりました。
    • 実際にコーディングもプロジェクトもやってみることが一番だと思いました。
  • 案件を考えるときに「機械学習」という選択肢を持てるのは、プロマネとしては強みにな今後なりうるのだろう思います。
    • ただ、選択肢の一つということを意識することは重要
    • 機械学習を使う!と言いながら、やはりいちばん大切なのは、「ユーザーの課題は何か?」という問いに尽きると改めて思いました。
  • 実際に、知見がない中で初めてプロジェクトを進める場合は、関わるメンバーや案件は慎重に進めるとよいと思います。
    • 時代の後押しはあるので、比較的会社も挑戦を応援してくれると思います。
Pocket

Leave a comment | Categories: Machine Learning

関数型言語、聞いたことあるけど結局何なの?

24 December 2018 by Okita

概要

エニグモ サーバーサイドエンジニアの @gugu です。
この記事はEnigmo Advent Calendar 2018の24日目です。

関数型言語って結局何なの?と思ったので調べてみました。私が疑問に思ったことをベースに調べた内容を記載していこうと思います。

※関数型言語として主にHaskellをメインに調べているので、関数型言語すべての話ではない記述があるかもしれません。

対象者

  • オブジェクト指向は知っているけど、関数型言語は知らないって方。
  • 私と同じような関数型言語への疑問を持っている方。

参考書

参考サイト

ありがとうございます!

関数型言語の疑問

「関数型」っていうけど手続き型でもオブジェクト指向でも関数を書くじゃん?

私がはじめに思った疑問です。みなさんもそう思いませんか?
下記のようです。

  • 関数型言語の関数というのは副作用のない純粋な関数のこと。(詳しくは後述)
  • すべてが関数でできている。Haskellだとif文も関数なのでelseの省略は不可。※言語によってそれぞれ例外あり。(そもそも何か値を返すのが「関数」、返さないのが「プロシージャ」と呼ぶ。C言語からプロシージャも含めて「関数」と呼ぶようになったとか。)
  • オブジェクト指向ではクラス内に関数を書く。(お作法的に。なぜこんな話をするのかは後述)

関数型言語の中でもマルチパラダイム言語って両方使えて最強じゃね?

結論から言うとそうでもないらしいです。

その前に関数型言語の種類について説明。。。

  • 純粋関数型言語 → その名の通り関数型のみ。例:Haskellとか
  • マルチパラダイム言語 → 関数型とオブジェクト指向の両方の仕組みを備えている。例:Scalaとか

オブジェクト指向が備わっているということは副作用が発生する可能性が増えるということ、つまり関数型言語の本来の目的とズレてしまっていることになります。(もちろん適材適所でオブジェクト指向と関数型で使い分けられるメリットはあるかと。)

別に関数型言語でなくてもオブジェクト指向で副作用なく作れば良いのでは?

まずは先に副作用がないとはどういうことか

雑な説明かもしれませんが、変数が途中で変わらず参照透明であることです。

束縛

関数型言語で変数に「代入」することを「束縛」と呼びます。代入と違う点は一度値を入れると変更できません。

x = 1
x = 2 -- error

参照透過性

引数が同じなら返り値も必ず同じになる関数のことを「参照透過性」と言います。

で、オブジェクト指向でも参照透明に書けば良いのでは?

その通りで、オブジェクト指向でも副作用を避けて書くことは大事です。ですが、そもそも言語としてのアプローチが異なります。

  • 関数型言語:副作用を排除する。というより普通に書けば排除される。
  • オブジェクト指向:カプセル化して副作用を内側へ隠蔽する。

関数型言語は副作用が起きづらい?だから?

下記メリットがあります。

  • テストや保守を容易にする
  • バグがおこりずらい
  • 再利用可能な部品を作りやすい
  • (注目)遅延評価

遅延評価

副作用がないので実現可能に。
使用するときに一度だけ計算されキャッシュされます。無駄な処理を省くことができます。

関数型言語ってどうやって書くの?

これが代表例なのかわかりませんが、私が一番なるほどと思ったのはループ文です。
関数型言語は関数がメインなのでループをさせる際はfor文ではなく再帰を使用します。(Haskellだとそもそもforもwhileも無いみたいです。)

Wikipedia(関数型言語)

で、オブジェクト指向、関数型言語どちらで書くべき?

すみません、わからないです。。。(汗)
個人的な意見だと、やはり堅牢でテストコードの書きやすい関数型言語がベターなような気がしますが、オブジェクト指向のほうが「オブジェクト」を自然と意識して作れるので設計しやすいような気もします。ただ書き慣れているだけかもしれないのでやはり関数型言語なのでしょうか。

関数型言語の勉強にScalaは向いていないかも。。

関数型言語の勉強でScalaを勉強していたのですが、結局はオブジェクト指向脳を使ってオブジェクト指向で書いてしまうので、なにが関数型言語の特徴なのか理解しづらいです。関数型言語を学びたければ純粋型を学ぶのが良いかと思います。

まとめ

実際私が関数型言語への疑問を中心に書いたので、偏った知識かもしれません。しかし同じような疑問を持っている方に少しでも役にたてばと思って書いてみました。

調べた感じだと関数型言語は良いことづくしなような気もしますが、数学的でやはりとっつきにくいイメージも大きいかと思いました。結局は「関数型言語を知りたければ関数型言語で書くべし!」なんでしょうね。。関数型言語と仲良くなれるようにがんばります!

Pocket

Leave a comment | Categories: Uncategorized

Codableいいよ!

23 December 2018 by PPAP

この記事はEnigmo Advent Calendar 2018の23日目です

こんにちは。iOSチームでエンジニアをやっています。

Codable使ってますか?

iOSチームでは、 Alamofire + Codable で ネットワークまわりの実装を行なっています。

最初はいいのかわからなかったのですが、今ではなくてはならないものになっています。

すごく便利すぎて、Codable無しじゃ開発できない!そんな生活を送っています。

Codableについて軽く説明からの、実際使ってみて、Codableの得意なところと苦手なところを書いていこうと思います。

TL;DR

  • Codable良いから使ってみて!
  • Codableになれると、Enumをたくさん使うようになる

Codableとは

Swift4からFoundationに追加されたtypealiasです。 ( Codableは、プロトコルではありません )

EncodableDecodableの二つプロトコルに準拠します。

https://developer.apple.com/documentation/swift/codable

Codable、何に使うの?

JSONを扱う際の、エンコード / デコード を Codableを使い、簡易に表現します

どうやって使えばいいの?

例えば

itunes.apple.com から取得できるJSONから今リリースしているアプリのVersion知りたい!という時に、使えます。

JSON:

{
    "resultCount": 1,
    "results": [
        {
            ....
            "sellerUrl": "https://www.buyma.com",
            "trackName": "BUYMA(バイマ) - 海外ファッション通販アプリ",
            "currentVersionReleaseDate": "2018-12-12T06:02:14Z",
            "version": "3.3.0",
            "minimumOsVersion": "10.0",
            ...
        }
    ]
}

Codable:

struct AppInfoResponse: Codable {

    let results: [Results]

    struct Results: Codable {
        let version: String
    }
}

すごい簡単ですね。

Codableの良さ

Foundation 純正

  • 純正なので、Swiftのバージョンが上がった際に、オンタイムでアップデートされている
  • サードパーティのライブラリの場合、そのライブラリのアップデート対応が終わるまでXcode/Swiftのバージョンを上げれない

JSONDecoderのカスタムもいける

  • APIのレスポンス内のデータで、Date / DateTimeクラス が 2018-11-4 23:592018-06-24T23:59:59+09:00のように揃っていないケースがあります

    JSONDecoderdateDecodingStrategy.customにすることで、様々なケースのFormatに対応することができます

    decoder.dateDecodingStrategy = .custom {
        let container = try $0.singleValueContainer()
        let string = try container.decode(String.self)
    
        let formatter = DateFormatter()
    
        /// Date format: ISO_8601
        formatter.dateFormat = "yyyy-MM-dd'T'HH:mm:ssZZZZZ"
        if let date = formatter.date(from: string) {
            return date
        }
        formatter.dateFormat = "yyyy-MM-dd HH:mm"
        if let date = formatter.date(from: string) {
            return date
        }
    
        return Date()
    }
    

Codableの苦手なところ

nilで返さず、空文字で返すと失敗する

  • URLがあるけど、URLになっていない
struct UserResponse: Codable {

    let name: String
    let imageUrl: URL?

    enum CodingKeys: String, CodingKey {
        case name
        case imageUrl = "image_url"
    }
}

成功:

{
    "name": "P",
    "image_url": "https://www.buyma.com/image"
}

失敗:

{
    "name": "P",
    "image_url": "" // 空文字
}

対応策

  • image_urlを 空文字ではなく、nilにしてもらう
  • init(from decoder: Decoder) を実装する

e.g.:

init(from decoder: Decoder) throws {
    let container = try decoder.container(keyedBy: CodingKeys.self)
    name = try container.decode(String.self, forKey: .name)
    imageUrl = try? container.decode(URL.self, forKey: .imageUrl)
}

Arrayの中に、様々な Classが混ざっているケース

"topics"の各Objectの"type"を見ないといけない:

{
    "topics": [
        {
          "type": "sale",
          "title": "夏のセール開催中!",
          "products": [
          ]
        },
        {
            "type": "news",
            "title": "夏のセール開催中!",
            "image_url": "https://www.buyma.com/image",
            "link": "https://www.buyma.com/"
        },
        {
          "type": "topic",
          "title": "韓国ブランド集めました!",
          "search_url": "https://www.buyma.com/search"
        }
    ]
}

対応策

  • type見るCodableを使って、一度どのtypeになるのかを判定してから再度デコードする

チームでCodableをどうやって使っているか

開発フロー

  • APIをcURLで叩いてjsonを取得
  • Codable準拠したstruct Responseを作成する
  • cURLで取得したjsonファイルを使用してstruct Responseにデコードされるかテストを実装する

サンプルコード

ネットワーククライアントのデコード処理:

func decode(_ type: T.Type, from data: Data) -> T? {
    do {
        return try decoder.decode(type, from: data)
    } catch {
        print("---- API Parse Error ---")
        print(String(bytes: data, encoding: .utf8) ?? "")
        print("Error Description: \(error)")
        return nil
    }
}

Codableができているかどうかのテスト:

class ResponseTests: TestCase {

    func testDecodeResponse() {
        guard let path = Bundle(for: type(of: self)).path(forResource: "ResponseSample/sample", ofType: "json"), let fileHandle = FileHandle(forReadingAtPath: path) else {
            fatalError()
        }

        guard let response = decoder.decode(SampleResponse.self, from: fileHandle.readDataToEndOfFile()) else {
            fatalError()
        }

        XCTAssertNotNil(response)
    }

}

まとめ

  • Codableにすることで、CodingKeyに準拠したCodingKeysを書かないといけない手間はありますが、それを書いてもメリットが大きいです
  • 苦手はありますが、API設計に起因する部分が多いと思うので、チームでAPIを相談する際に、何が苦手なのかを伝えるといいと思います
  • SwiftyJson, ObjectMapperと使っていましたが、ほぼCodableに移せました
Pocket

Leave a comment | Categories: Uncategorized

← Older posts