ソフトウェアエンジニアを募集しています
Jun 3, 2019 タベリーという、料理と買い物の負担を肩代わりするモバイルアプリをつくっています。最近、オンライン注文機能をリリースして、いよいよ買い物の領域にも本腰を入れ始めました。また、会社の資金調達も同時に発表しており、このタイミングで仲間になってくれるソフトウェアエンジニアも募集しています。 https://10x.co.jp/news/2019-05-14.html 会社が取り組んでいる課題や市場、文化については下記のスライドにまとまっています。 どんな人を求めているか 一言で言えば、チームの可能性を広げられる人を求めています。いまは7名の小規模チームでなんとか市場にエントリーできる場所に漕ぎ着けました。しかし、あるべき体験に到達するためには、解決しなければならない問題がたくさんあります。チームに新しいメンバーを迎えることで、これまでのチームでは出来なかったことを出来るよう
iOSのCI環境をCircleCIに移行した
Feb 8, 2018 移行前はBitriseの$50のプランでiOSのCIをしていました。最近はサーバーやAndroidの開発もやっているのですが、そちらのCIには元々CircleCIを使っていて、workflowの使いやすさやページの軽快さが気に入っていました。 CircleCIのmacOSマシンは$39から始められるのですが、一定時間以上使うとそこから従量課金制になります。CircleCI上でのビルドにどのくらい時間が掛かるか完全には読めなかったので、実際に移行してみて費用が安くなるのか高くなるのか不確定だったというわけです。そういう状況だと、わざわざ確認のために新しい環境でCIをセットアップするのも億劫に感じてしまい、なかなか手をつけられずにいました。 ところがある日、サーバーのリソースを見直した結果、月に$250ほど節約できることがわかりました。なぜかその時に背中を押されて、iO
Storyboardとの付き合い方 2018
Aug 12, 2018 少し前に、自分のStoryboardの使い方をツイートしたら割と反応があったので、改めてまとめてみようと思います。これまで何年かiOSアプリの開発をしてきて、Storyboardとの付き合い方は何度も変わりました。なので、今回紹介するものはあくまで2018年現在のもので、来年には変わっているかもしれません。 説明のイメージを掴みやすくするため、画面の例を用意しました。左が編集時のStoryboardで、右が実行時のiOSシミュレーターです。具体的なトピックが出た時に、この例を説明に使うことがあります。 記事の最後にこれが動作するサンプルコードも用意しましたので、興味があればどうぞ。 Storyboardを使う目的 以下の2つを重視して、Storyboardを選択しています。 動作確認に掛かる時間を短縮する 成果物の構造を把握しやすくする ただし、Storyboar
モバイルアプリでgRPCを使う
Feb 7, 2018 最近は、モバイルアプリとサーバーの通信にgRPCを使っています。gRPCは、サーバー同士の通信では徐々に使われ始めている印象がありますが、モバイルアプリでの使用例はまだ少ないと思うので、動機とか、感想とか、ウチはこうしてるというものを共有します。 リクエストとレスポンスの定義を1箇所にまとめる 今のプロジェクトでは、同じデータをサーバー, iOS, Android, Webで扱う予定がありました。普通のREST APIでは同じデータを4つの言語に翻訳する必要がありましたが、これをprotoへの翻訳の1回だけで済ませたいというのが、gRPCを使う最初の動機でした。 gRPCでは、リクエストとレスポンスの全ての情報をprotoファイル上で表現し、それを元に各言語のコードを自動生成します。APIドキュメントを人間が各言語に翻訳する場合と比べると、コードを書く手間が省けます
モバイルアプリでgRPCを使う
Feb 7, 2018 最近は、モバイルアプリとサーバーの通信にgRPCを使っています。gRPCは、サーバー同士の通信では徐々に使われ始めている印象がありますが、モバイルアプリでの使用例はまだ少ないと思うので、動機とか、感想とか、ウチはこうしてるというものを共有します。 リクエストとレスポンスの定義を1箇所にまとめる 今のプロジェクトでは、同じデータをサーバー, iOS, Android, Webで扱う予定がありました。普通のREST APIでは同じデータを4つの言語に翻訳する必要がありましたが、これをprotoへの翻訳の1回だけで済ませたいというのが、gRPCを使う最初の動機でした。 gRPCでは、リクエストとレスポンスの全ての情報をprotoファイル上で表現し、それを元に各言語のコードを自動生成します。APIドキュメントを人間が各言語に翻訳する場合と比べると、コードを書く手間が省けます
株式会社10Xを始めました
Jan 1, 2018 去年の7月に、メルカリで同僚だった矢本さん(@yamotty3)と株式会社10Xを始めました。矢本さんが代表で、自分は開発全般を見ています。会社やプロダクトのストーリーは矢本さんのポエムに任せることにして、自分はエンジニアとして会社を立ち上げた雑感を書きます。 仕事を選ぶ理由は人それぞれですが、同じ人でも時期によって何を重視するかは違ってくると思います。新卒時に重視していたことは「開発ができるようになれること」でしたが、今の自分は少し変わって以下の3つを重視しているようです。 人が抱えている問題を解決すること 技術の幅を広げること チームとして機能すること いざ書いてみると月並みという感じですが、、。会社を始めるということをあまり想定していなかったタイプなのですが、それでも踏み切れた理由は、この3つがきちんと満たせそうだと思えたからではないかと思います。 以下、それ
iOSDCで「コード生成による静的なDependency Injection」について話した & 口頭原稿を公開
Sep 18, 2017 このところかなり忙しく、iOSDCでちゃんとしたことを話せるのか不安でしたが、なんとか無事に終わりました。あまり会場を盛り上げることができず、後半はしどろもどろで死にたくなりましたが、面白かったと言ってくれた方もそれなりにいたので少し安心しました。 DIは今回の話以外にも色々なことに挑戦していて、最初はデフォルト引数を使った手動のinitializer injectionから始めて、SwinjectやCleanseなどのライブラリを試してみたり、Cake Patternを模倣してみたりしていました。それらを通じて、自分が求めるDIのプラクティスは 依存の宣言とインスタンスの取得のためのコードが単純かつ十分に少ない コンパイル時に依存関係の解決が検証される というものだとわかりました。もしも「dependencyの宣言さえしておけば、あとはコンパイルエラーを直してい
APIKit: レスポンスに応じた独自のエラーを投げる
{ "message": "Validation Failed", "errors": [ { "resource": "Issue", "field": "title", "code": "missing_field" } ] } 今回は、このようなエラーをリクエストの呼び出し側に伝える方法を説明します。なお、この説明はDefining Request Protocol for Web Serviceのエラーの扱いをもう少し詳しく説明したものとなります。 サービス用のリクエストプロトコル APIKitでは、特定のサービス(Web API)向けのリクエストの特徴をまとめるために、サービス用のリクエストプロトコルを定義します。今回はGitHub APIを例としているので、baseURLのデフォルト値がhttps://api.github.comとなっているGitHubRequestを定義しま
antitypical/Resultの良いところ
また、元のコードのvalue, errorは両方ともOptionalなので、以下の4つの組み合わせが存在します。 None, None None, Some Some, None Some, Some 元のコードは(None, None)と(Some, Some)を考慮していません。 つまり、実行時には(None, Some)と(Some, None)の2パターンしか存在しないという約束を前提としたコードとなっています。 Resultを利用するとそのような約束を型で表すことができ、2パターンしか存在しないことがコンパイル時に保証されるようになります。 Cocoaの伝統的なメソッドに対してもResultを使用できます。
TestSchedulerとSessionAdapterTypeを使った仮想時間上のテスト
May 7, 2016 TestScheduler RxSwiftにはVirtualTimeSchedulerというSchedulerがあって、仮想的な時間でイベントストリームを扱えます。仮想的な時間というとなんだか難しそうですが、要は時間を自分で操作できるSchedulerということです。 RxSwiftのテストライブラリのRxTestsには、TestSchedulerというSchedulerも用意されています。これはVirtualTimeSchedulerにテスト向けの機能をつけたもので、イベントを記録できたりします。記録したイベントはXCTAssertEqual(_:_:)で検証できるので、どの時刻にどの値が来くるかテストできるというわけです。 func test() { let scheduler = TestScheduler(initialClock: 0) let obser
iOSDCでRxSwiftを紹介してきた + ReactiveCocoaの補足
Aug 23, 2016 オタクなのでRxSwiftの話になるとつい早口にアレコレ喋りまくってしまうのですが、今回はそういった気持ちをそっと胸にしまって、RxSwiftを導入するとアプリ開発にどういう変化が起こるのか、なるべく多くの方に伝わるように心がけて話しました。 スライド: http://blog.ishkawa.org/talks/2016-08-20-iosdc/ ビデオ: https://abemafresh.tv/tech-conference/32381 (1:00:00~) 3行で書くと以下の通りです。 RxSwiftはイベントストリームをObservableで抽象化するライブラリ 大抵のイベント処理はObservableからObserverへの接続で実装できる イベントストリームの依存関係はオペレーターから読み取れる その他、以下の3つについても話そうと思っていましたが
try! Swiftにスピーカーとして参加しました
Mar 12, 2016 良いセッションはたくさんあったのですが、書き切れませんね。 平常心で型を消し去る (Gwendolyn Weston) Associated Typeを持つプロトコルは型制約でしか使えないため、型パラメーターが利用側に波及しがちになるという問題があります。セッションでは型パラメーター地獄について話していなかったと思いますが、紹介されていたAnyPokemonのようなパターンは(表面上の)型を消すことでこの問題を解決できそうだなあと思いました。また、このパターンはRxSwiftでもAnyObserverで使われています。 完全に余談ですが、Gwendolyn Westonさんはスピーカーディナー後のカラオケパーティでモーニング娘のLOVEマシーンを歌っていて、めっちゃ上手かったです。 Swiftのエラー処理についての三つの話 (Yuta Koshizawa) Swi
2015年
Dec 31, 2015 2015年にあったことのまとめ。 APIKit 2月に開発を始めて、もう少しで500 starsとなりそう。はじまりは標準ライブラリを読んでいたときで、SequenceTypeなどのプロトコルがtypealias(associated type)を持つという設計にえらく感心して、それをWeb APIに持ち込んだのがAPIKitだった。0.0.1では以下の2つのプロトコルしか提供していなくて潔い。 public protocol Request { typealias Response: Any var URLRequest: NSURLRequest { get } func responseFromObject(object: AnyObject) -> Response? } public protocol API { class func sendReque
#potatotips でAPIKitを紹介してきた
Mar 13, 2015 資料 内容 Appleが出しているThe Swift Programming Languageに”Swift is a type safe language.”書かれているように、 SwiftをSwiftらしく書くには型を意識したコードを書くのが良いと思っています。 型を意識する前は以下のようなAPIクライアントを使ってきたのですが、 let parameters = [ "q": "APIKit", "sort": "stars", "order": "asc", ] GitHub.call(.GET, "/search/repositories", parameters) { JSON, error in if error != nil { println("error: \(error!.localizedDescription)”) } else { se
Circle CIでiOSアプリのリリース作業を自動化
Jan 7, 2015 ※ 現在(2015/01/07)Circle CIのiOSビルドはベータとなっているため、利用するにはサポートへの連絡が必要です。 できること GitHubへのコミット毎に以下のタスクを実行します。 ユニットテストの実行 ipaの作成 ipaのバリデーション CrittercismにdSYMをアップロード Circle CIにテストレポートを出力 iTunes Connectにipaをアップロード これらの作業を自動化すると、masterブランチにgit pushするだけでテストが通ったアプリがiTunes Connectに登録され、 TestFlight(新)からダウンロードできるようになり、そのままApp Storeに申請することまで出来るようになります。 Circle CIのメリット 無料(1 container) 見た目がきれい private reposi
すべてのテストケースの前後にあれこれする
Apr 30, 2014 iOSのアプリケーションテストを書いていると、各テストケースの前後に永続ストアやスタブサーバーなどをリセットしたくなることがあると思います。 リセットが必要なテストスイートのsetUp/tearDownに書いても良いのですが、書くのが面倒だったり書き忘れてしまうこともあるので、 すべてのテストケースについてリセットが走るようにしておいた方が心を穏やかにすることができると思います。 実現方法 すぐに思いついたのは以下のような方法です。 setUp/tearDownにリセット処理を加えたサブクラスを継承させる XCTestCaseのsetUp/tearDownをswizzleする サブクラスを継承させる方法には、KIFTestCaseなど他のライブラリのクラスには適用ができないという問題があります。 method swizzlingを利用する方法は、他のmethod
NSRunLoop+PerformBlockをCocoaPodsに登録
NSRunLoop-PerformBlockをCocoapPodsに登録しろLINE株式会社— laiso(レイソー) (@laiso) 2014, 5月 27 なぜかテスト関連のツールはマジカルな実装が多いのですが、自分は愚直にテストをしたいので愚直なライブラリを書きました。 書いたのは半年前だったのですが、需要があったのでCocoaPodsに登録しました。 ざっくり説明すると、以下のようなものです。 引数に渡したblockの実行中はNSRunLoopを回してテストケースが終了しないようする *finish = YESとするとblockから抜ける タイムアウトした場合は例外を投げてテストケースを失敗させる NSRunLoop+PerformBlock 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 - (void)testPerformBl
XCTest + iOS 7でCoverallsを利用する
XCTest + iOS7でテストを実行しても上手くコードカバレッジが取得できずに困っていたのですが、 最近@tokoromさんが取得できる方法を紹介していたので、 そちらを参考にして対応してみました。資料は以下のものです。 My unit test environment for Objective-C Coverallsに対応したライブラリは以下のものです。 ISHTTPOperation ISDiskCache ISMemoryCache NSRunLoop+PerformBlock 対応の肝となるのはISGcovFlusherをテストターゲットに追加しておくことです。 これを追加することでテスト終了時に__gcov_flush()を自動的に呼んでくれて*.gcdaが出力されるようになります。 なお、__gcov_flush()を呼び出すにはBuild Settingsの”Instr
JSONにNSNullが入ってきたとき
多くのiOSアプリはサーバーとの通信が必要で、やりとりされるデータのフォーマットにはJSONが採用されることが多いと思います。 iOS 5からは標準ライブラリにNSJSONSerializationが導入され、特に理由がなければJSONのエンコード/デコードにはこれを利用します。 NSJSONSerializationが扱うオブジェクトは以下の5種類のオブジェクトです。 NSString NSNumber NSArray NSDictionary NSNull そこで心配になるのが、予期しないところにNSNullが入ってきて”unrecognized selector sent to instance.“となってしまうことです。 NSNullではなくてnilが入っていてほしいと考える人は多いようですが、そもそもNSArrayやNSDictonaryはnilを含むことはできず、 そのような状
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デバッグ中にJSONをサッと出力する