巨大 Pull Requestを避けるための9つのポイント - Qiita
巨大 Pull Requestの問題 レビューに時間がかかる、疎かになる テストとコードを照らし合わせが大変 本番で問題が起きたときに、問題の切り分けがしにくい masterとの差分を反映する際のレビューが難しくなる 一つのミスが大きなfeatureブランチになるきっかけになることも 大きくなるとmergeに時間がかかり、ますます大きくなる どのようにして大きなPRを避けるか PRが大きくなりそうな時は事前に相談する 作業しているときに、変更点がたくさん必要になったときは早めにレビューアーに相談する 複数人で開発しているときは、しっかり話す時間をとる PRが大きくなる問題は後で変更するのが難しいので、最優先で相談するとよい。近くにいるなら直接相談する。いないときはチャットで相談する。 モデルだけの変更とテストを書く なにか機能の変更がある時に、まずモデルからレビューする 実際にどういう変化
iOS開発する上で絶対に押さえておく8つの項目 - Qiita
レスポンスはキャッシュされる NSURLConnectionでもAFNetworkingでも、レスポンスは設定によってはキャッシュされます httpのレスポンスコードを正しく返す必要があります。 サーバーからのjsonのレスポンス、画像のキャッシュの設定をしっかりみる必要があります 特に、普段返さないエラーページやメンテナンスページの設定を確認する必要あり バージョンコントロール 下位バージョンをサポートしないことで、インストールがかなり落ちます。 一度間違えて、7.1のときに7.0以降でなく7.1以降という設定でリリースして3割ほどインストールが落ちました cocoapodを利用している場合は、Podfileに書いているバージョンとprojectのバージョンに違いがあるかも注意する必要があります。 特定の7.0.2だけviewが崩れる問題などもありました iOSの細かい設定の違い カレン
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
awakeFromNibとinitWithFrameとinitWithCoderの使い方 - Qiita
initWithFrameとinitWithCoderの違い initWithFrameは、code上でobjectを作る時に呼ばれる initWithCoderは、interface builder(storyboardやnibファイルなど)からobjectを作るときに呼ばれる initWithCoderとawakeFromNibの違い initWithCoderでは、IBOutletやIBActionはロードされていない、awakeFromNibはロードされた後に呼び出される interface builder(storyboard)使ってて、なにも考えず使いたいならawakeFromNibを使うといいのでは initWithFrameとinitWithCorder両方呼び出す可能性があるviewの場合は、initWithCorderで書くこととawakeFromNibで書く内容を分け
Aggregateを使って、archiveのときだけrun scriptを実行する - Qiita
archiveのときだけ実行したい aggregateをtargetに追加する。(Editor > Add Target) 追加したaggregateのBuild Phasesにrun scriptを追加する schemaを変更してarchive時だけ、targetを実行する もともと、crashlyitcsのrun scriptをarchiveのときだけ実行したかったので、上のようにaggregateを作成して実装したけど、ダメだった。。理由は、build settingを見てcrashlyitcsのrun scriptは実行されるから。 buildsettingに関係なく実行するscriptで、archiveのときだけ実行したいならいいかもしれない configurationがReleaseの時だけ実行したい これでも毎回buildすることはなくなる releaseConfig="Re
githubをブラウザでフル活用する方法 - Qiita
commitに移動する https://github.com/wantedly/wantedly/tree/**** branck名でもcommit番号でもtag番号でも大丈夫 ディレクトリに移動する https://github.com/wantedly/wantedly/tree/master/directory_path masterをcommit番号などに変更する ファイルを表示する https://github.com/wantedly/wantedly/blob/master/file_path masterをcommit番号などに変更する historyを見る https://github.com/wantedly/wantedly/commits/master/file_path blobをcommitsに変更 masterをcommit番号などに変更する git blam
static cellとcontainerを利用して、controllerを分割する実験 - Qiita
概要 いくつかのcontainer viewの表示と非表示の切り替えを行う。 縦に切り替えを行うためにtable view controllerのcellの高さを調節する。 container view controllerの表示 static table Cell上にcontainerを設置。 containerにviewControllerをセットして表示する。 cellかどうかの判定は、cellの比較によって判定し、heightは自分で定義する。 static CGFloat const kViewControllerCellHeight = 300; @property (nonatomic, weak) IBOutlet UITableViewCell *viewControllerCell; - (CGFloat)tableView:(UITableView *)tableVi
StoryboardとContainerを多用した開発のメリットとデメリット - Qiita
Wantedlyで実際に開発しているstoryboardの一部公開してみました。 うまくいったなということをまだ公開してないアプリの実例を見せながら紹介します。 初めて作ったアプリでは、Containerの存在を知らず、TableViewをScrollViewControllerに埋め込んで、ページャーなどを実装していました。そのため、どうしてもコピペの多いアプリを作ってしまってました。 今回は、Viewの中にContainerをたくさん設置して、一覧を表示させる必要があるパーツはすべてUITableViewControllerを継承して作成しました。 その結果、 一覧画面を表示したり、 ローディングを出したり、 通信失敗後の更新ボタンを設置したり、 することが、ある共通のUITableViewControllerを継承したクラスを使うことで実装できました。 ※ スクリーンショットはまだ開
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
