タグ

ブックマーク / konifar.hatenablog.com (9)

  • KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP

    2020年1月から1年ほどKyashEMをやっています。 今までチームをリードしてきたことは何度かありましたが、いわゆるマネジメントという役割は初めてでした。EMについて抽象化した話ができるほど自分の中で咀嚼できているわけではありませんが、思考整理を兼ねてやってきたこととやっていくことをまとめておこうと思います。 ここに書く内容は当然自分だけでやってきたわけではありません。他のメンバーによって支えられてきたことの方が多いです。文章量の都合で端折ることもありますが、自分だけで色々やってきたみたいに捉えられるとなんだかむず痒い気持ちになるので一応前提として書いておきます。 1~6月 : Android/iOSチームのEM 1月にiOSエンジニアが1名入社したタイミングで、Android/iOSチームのEMをやることになりました。 それまではTechチーム全体を@ymzkmctが見ていましたが

    KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP
  • Kyash Android で UIテストを導入した時の方針 - Konifar's WIP

    先日、KyashAndroidアプリのUIテストをEspressoで書いてCIで回すようにしました。 ユーザー登録、ログイン、カード登録のテストが、毎晩元気に走っています。 きっかけはKPTです。iOSでログイン直後に発生するユニットテストでは気づけない問題が見つかり、 Problem として上がってきました。 テストケースを15項目くらいSpreadSheetにまとめていて大きなリリースの時は手動で確認していたのですが、なぜか「今回はやらないで大丈夫」と判断した時に限ってバグが発生するんですよね。また、手動のテストケースはミスや形骸化しやすいので、 Try としてテストケースの一部を自動化してみることにしたのでした。 Espressoでテストを書く時は、@sumio_tymさんの素晴らしい資料があるので、下記2つを読んでおけば間違いないと思います*1。 DroidKaigi2017

    Kyash Android で UIテストを導入した時の方針 - Konifar's WIP
  • Kyashに入社して半年くらい経ちました - Konifar's WIP

    早いもので、2017年12月にKyashに入社してから半年が経ちました。 最近は 「勢いある」「Kyashよさそう」と言っていただくことも増えてありがたいなぁと思うと同時に、中にいるとちょっと過大評価されているなと感じることもあります。 自分自身も後で見返せるように、実際どうなの?という話を自分の視点から書いておこうと思います。Kyash実際はこんな感じなんだーというのがなんとなく伝われば嬉しいかぎりです。 ちなみにこういう話は思いもしないところ思いもしないツッコミを受けるものなので結構緊張しています。何か気になる表現があれば@konifarまで直接連絡をもらえるとありがたいです。 入社直後の感想 2017年12月に入社した時、Kyash社内はめちゃくちゃ忙しい時期でした。開発もマーケも全員修羅場で、「オッやっとるな」という感じでした。 自分が入った時にすでに佳境だったので、そのプロジェク

    Kyashに入社して半年くらい経ちました - Konifar's WIP
  • FlutterでDroidKaigi 2018のiOSアプリを作りました - Konifar's WIP

    DroidKaigi2018が来週に迫ってきましたね。 自分もコードで見るFlutterアプリの実装というテーマで発表します。 その題材として、DroidKaigi2018のiOSアプリを作りました。コードも公開しています。 github.com 作った理由は、以前の記事に書いたとおりです。 また、公式アプリではないですが今年はiOSアプリも用意したいなぁと思っています。iOSDC2017に参加した時にAndroidアプリが欲しいと思ったからです。 まだ申請中なので間に合うかどうかわかりませんが、iOS端末がメインの方に使っていただけると嬉しいです。 DroidKaigiの発表では、時間の都合上Flutterの基的な部分の説明は省くつもりなので、ここで簡単にまとめておこうと思います。 Flutterとは Flutterは、iOS / Androidで動くアプリを作れるクロスプラットフォー

    FlutterでDroidKaigi 2018のiOSアプリを作りました - Konifar's WIP
    to4iki
    to4iki 2018/02/01
    Flutter!
  • iOSDCで『Sketchからアイコン切り出し ⇒ Asset Catalogを自動生成 ⇒ 差分があればPullRequest』という流れをCIで自動化する話をしました - Konifar's WIP

    2ヶ月くらい前にiOSDC 2017のプロポーザルを出したんですが、2つ出したうちの1つが採択されたので登壇してきました。 speakerdeck.com サンプルリポジトリはこちらです。資料だけだとわかりにくい部分もあると思うので、少し補足しておこうと思います。 Import Sketch Icons to Asset Catalog on CI Sketchからアイコンを切り出して、Asset Catalogを生成して、差分があったらiOSのリポジトリにPull Requestを出すというのをCIで自動化している話です。 私の所属するQuipper Limited.で実際に運用している知見です。 @konifar konifarという名前で、TwitterGitHubをやっています。 プライベートで、専業主婦の嫁さんとエンジニアリングやエンジニア仕事に関する雑談をするyome.fm

    iOSDCで『Sketchからアイコン切り出し ⇒ Asset Catalogを自動生成 ⇒ 差分があればPullRequest』という流れをCIで自動化する話をしました - Konifar's WIP
  • DroidKaigi 2017 アプリコード公開してから10日経ちました - Konifar's WIP

    DroidKaigi 2017のアプリのコードを公開して10日ほど経ちました。 忘れないうちに今の状況をざっとまとめておこうと思います。 konifar.hatenablog.com PullRequests、Contributors こ10日間のPullRequestは200件くらいでした。Contributorsは60人くらいです。すごくたくさんの方々に毎日修正や改善を送っていただいて、当にありがたいかぎりです。 公開して5日間くらいは1日30件くらいPullRequestが来ていました。あまりに速すぎて、Issueにアサインしても同じPullRequestが30分くらいの差で送られてきたこともありました。迷惑をかけてしまって申し訳なかったです。 コンフリクトしてしまうと申し訳ないので、基的にPullRequestはすぐに見ています。小さい修正であれば即LGTMを出し、CIが完了し

    DroidKaigi 2017 アプリコード公開してから10日経ちました - Konifar's WIP
    to4iki
    to4iki 2017/02/19
    まさにみんなで作るカンファレンス感がある
  • DroidKaigi 2017 公式アプリのコードを公開しました - Konifar's WIP

    去年、DroidKaigi2016の公式アプリをオープンソースで作りましたが、2017もコードを公開しました。 github.com コードだけではわかりにくいところを少し補足しておきます。 2016とは別アプリ 2016とはリポジトリもパッケージも違います。別アプリです。 なぜ去年のリポジトリを引き継がなかったかというと、個人のリポジトリではなくDroidKaigiのリポジトリとして管理したかったというのが1つ。もう1つは、同じアプリをメンテナンスしてると飽きちゃうし、またゼロから作りたかったからです。 余談ですが、カンファレンスアプリに必要な機能はほぼ決まっているので、モデルや画面をガチガチに固めて設定ファイルとリソースを用意するだけで作れるライブラリに切り出してもいいかもなと考えています。 Kotlin メインはKotlinではなくJavaで作っています。コトラーが「Kotlin一択

    DroidKaigi 2017 公式アプリのコードを公開しました - Konifar's WIP
  • potatotips #28 Android発表まとめ - Konifar's WIP

    モバイルアプリの知見共有会であるpotatotipsにブログまとめ枠で参加してきました。 potatotips.connpass.com 会場は外苑前にあるエウレカさんのシャレオツなオフィスでした。 資料はいつものGitHubリポジトリに上がると思うので、Androidの発表を聞いて自分が考えたことをメインにざっくりまとめます。 API仕様書をいい感じに管理する yuyakaidoさんによる、アプリとサーバーサイドのAPI仕様の共有に関する知見の共有でした。 speakerdeck.com 「APIのレスポンスがサーバーと違う」「APIの開発待ちでアプリの開発が止まってしまう」といった、ありがちな問題を、APIドキュメントサービスを使って解決しようという話でした。ApiaryとSwaggerの2つが紹介されていましたが、Swaggerの方がクライアントコードの生成ができるなどApiaryよ

    potatotips #28 Android発表まとめ - Konifar's WIP
  • AndroidではMVCよりMVPの方がいいかもしれない - Konifar's WIP

    Android開発していると、なんかMVCうまくいかないなぁとモヤモヤしてきました。そろそろ他のアーキテクチャを模索してみた方がいいんじゃないかと思い始めまして、ある程度考えがまとまったので自分なりの指針を残しておこうと思います。 そもそもアーキテクチャ必要なのか 世の中には色々なアーキテクチャが存在するんですが、なんか概念を読んでもスッと理解できることが少ないんですよね。これはなぜかと言うと アーキテクチャが解決しようとしている問題を理解できないからです。 極端に言うと、HelloWorldを表示するアプリにMVCを導入する必要があるの?って言うと答えはNoですよね。じゃあの名前をリストで表示するアプリだったらどうかと言われると、これもまだ必要ないかもしれません。 つまり、アーキテクチャを適用しなくても問題がないほど小さなアプリにおいては、ただ冗長になるだけなので別にいらないわけです。

    AndroidではMVCよりMVPの方がいいかもしれない - Konifar's WIP
  • 1