Every pixel. Every word. Every part of the experience aims to deliver on that promise.
Every pixel. Every word. Every part of the experience aims to deliver on that promise.
この記事において利用している.travis.ymlとRakefileの全体はGistにて公開しています。 ↓ Rakefileの全体はこちら gist.github.com/kishikawakatsumi/8918124 ↓ .travis.ymlはこちら gist.github.com/kishikawakatsumi/8918365 概要 ユビレジではiOS アプリを申請する際に発生する作業の大部分をCIで自動化しています。 申請の作業としてユビレジでは下記のワークフローを決めています。 1. リリースブランチを作る 2. リリースするバージョンのバイナリをビルドする 3. 2と同等のアプリケーションを社内に配布して最終チェックをする 4. クラッシュレポートのサービスとしてCrittercismを利用しているので、そこにデバッグシンボル(dSYM)をアップロードする 5. 2のバイ
Ted Kremenek is a member of the Swift Core Team and manages the Languages and Runtimes group at Apple. This post describes the goals, release process, and estimated schedule for Swift 3.0. Swift 3.0 is a major release that is not source-compatible with Swift 2.2. It contains fundamental changes to the language and Swift Standard Library. A comprehensive list of implemented changes for Swift 3.0 ca
GitHubは普通の会社とどう違うのか? リリースマネージャーがいない(いる必要がない) 週次のデプロイセットもありません(この週にこれだけの機能をまとめてリリースとかがない) 開発者とデザイナーは、早く提供できるように自分たちでデプロイする(できる)作った人達が自ら確認できて、サクッとデプロイできるのであれば、さっさと作って、ささと出してしまった方が良いに決まっています。これを実現させるために様々な工夫がされているようです。 GitHubの基本的なワークフロー The basic workflow goes like this: Push changes to a branch Wait for the build to pass on our CI server Tell Hubot to deploy it Verify that the changes work and fix a
http://blog.livedoor.jp/faulist/archives/1051536.html http://ameblo.jp/xcc/entry-10400027873.html インスタンス変数としてヘッダで宣言した変数は、deallocメソッドにてreleaseするのがメモリ管理の基本です。でも、後にreleaseするということは、allocで生成しておかないといけないんですね…。 message sent to deallocated instance というエラーメッセージがでて落ちまくりました。ファクトリメソッドで生成したものはautoreleaseされてしまうので、deallocがコールされたときにはもうそんな変数ないよ、ってことですよね。今まで意識しないでやってきたけど全く気づかなかったな〜。 NSStringのインスタンス変数を使ったアプリが落ちまくったこと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く