以下のリポジトリのcarthageディレクトリ以下に便利ツールを公開しました。https://github.com/toshi0383/scriptscmdshelfでのご利用が一部必須になっています。https://github.com/toshi0383/cmdshelfCarthageのイケてないところまずはなぜこういうものが必要だったのかの動機についてです。手作業多いCocoaPodsだと自動でやってくれるようなことも、Carthageでは手作業が必要になります。単純なことしかしないのがいいところなのですが、例えば以下のような作業は結構面倒なものです。追加/削除する更新時に古いbcsymbolmapを探して削除するCodeCoverage設定問題XcodeGenを使うと1つ目は気にしなくて良くなるのですが、どうしても後の2つは手作業と指差し確認が必要ですね。ある全部のリポジトリをfetchしてしまいます。依存関係がある場合に必要なのはわかるのですが、明らかに依存がないことがわかっている場合は、不要な処理ですよね。私の環境だと特にRxSwiftのfetchが延々終わらないことがあったので、そうなると結構辛いです。間違ってもControl+Cでキャンセルしてはいけません。processをkillすることができないらしく、非同期のfetch&buildのプロセスがゾンビ化します。標準出力に書いてきます。するか、終わるまでおとなしく待つしかなくなります。更新時に古いbcsymbolmapを探して削除するCodeCoverage設定問題どうしてもbcsymbolmapが見つからない場合もあるので、そういう場合はメッセージを出力してます。CodeCoverage問題が見つかった場合自動で直しますが、その場合ライブラリ管理者に連絡するよう促しています。YESになっていました。ライブラリ管理者に連絡するべきかもしれません。終わったらちゃんとCartfileとCartfile.resolvedは元に戻して、更新を反映します。CircleProgressButtonとか書いてもらえれば便利に使えます。CircleProgressButtonのようにプロセスに環境変数を渡します。どちらのスクリプトも泥臭い処理をベタベタ書いてるだけなので、ここでの解説は省きます。各スクリプト冒頭にドキュメントがあるので気になる方はご確認ください。まとめ仕事で必要に駆られて作ったものですが、公開したほうが色々いいことがあると思うので、公開できない部分は削除した上でとりあえず公開しました。使うことになっています。指定しているので、運用と合わない場合はごめんなさい。みなさんも似たようなスクリプトを書いて運用されているとは思うので、「こうしたほうがいい」や「もっといいツールがある」などあればぜひ教えてください。ツッコミや質問などブコメやTwitterで受け付けますのでお気軽にどうぞ。リポジトリへのプルリクもお待ちしています。*1:0.26.0以降のCarthageでは、CodeCoverage設定問題は解決しているようです。やってみたら不要なFetchが終わらなくなることはなかったので、もしかしたら最新版では挙動改善したのかもしれません。0.28.0で確認しました。同じくらいの規模だと以前360iDevというUSのカンファレンスに行ったことがあってエントリも書いたのですが、ちょっと割高な印象だったのですよね。それでもまあ会場の広さは余裕があるし、とてもアットホームで雰囲気が良かったし、でもトークはどれも刺激的で、という感じでした。それと同じか私にとってはそれ以上の楽しい時間を過ごせたので、このチケットの価格はもはや恐ろしいなという感じでした。ところで5月に子供が産まれまして、最近はなるべく明るいうちにお家に帰って奥さんの手伝いをしています。以前にも増して勉強会に行く頻度が減っていたこともあり、ひさびさに顔を合わせる方が多く、いやーほんと、忘れられてなくて良かったと思いました。話しかけるときドキドキしました。今回はCfPに応募を出したところLTが通りまして、以下の発表をさせてもらいました。speakerdeck.comただ、15分くらいならそれなりに経験はあるんですけど、そういえばLTって焦っちゃうのでもともと苦手だったのをすっかり忘れてたんですよね。練習はしてたし内容は伝わったかと思うのですが、最初と最後がマイペースにやりすぎてちょっとグダッとなってしまって、心もとない印象を与えてしまったかも。選んでもらったのに、悔しいです。これを糧にというか、今後は月1くらいで軽い発表をしていけるようにして、来年リベンジしたいと思ってます。何より最終日の最後って体力がないと全然もたないので、やはり私にいま一番必要なのは筋肉だと思いました🍖こういう大きいカンファレンスで発表側に立ったのってもしかしたら初めてだったのですが、他の偉大な発表者の方々とも距離が近くて(気のせい?)、結構いろんな方とお話しできたような気がします。新しい繋がりも私にしては結構できたような気がします。普段TwitterやQiitaでしか関わりがないと忘れがちな、それぞれの人間っぽい部分に触れることができて、やっぱりリアルでのコミュニケーションは大切だなと思いました。さんが実は冒頭「このセッションに来てくれてありがとうございます」のくだりで感極まっていて誤魔化すために必死だったというエピソードがあったりして、ほっこりしました。わからなかった笑という感じで、様々な知見はもちろん、とても前向きなエネルギーをもらいました。今回も始終和やかな雰囲気で和みました。NativeのAndroid版はどうやってJSとブリッジしているのだろう?という疑問が私を含む一部で湧いたので、Android詳しいわけでもないのですが、軽く調査。2017年2月11日メモ程度ですが何かのお役に立てば幸い。com/facebook/react/bridgeふむ、この辺に色々ありますな。GitHubcom/facebook/jniお、jniがいるということは。GitHubReactCommon/cxxreact/JSCExecutor.cppいましたーそれっぽいc++のクラス。loadApplicationScriptという関数でJSをロードしているっぽいですね。関数JSCreateCompiledSourceCodeという関数が使われており、名前からしてこいつがJSから実行形態に動的にコンパイルしているっぽい。この関数、ググっても出てこない。jscというモジュールがそれっぽいのだけど。GitHubcom/facebook/react/bridge/JavaJSExecutor.javaで、こいつがJSCExecutor.cppにブリッジしている子っぽいです。アプリ側からはこいつを介してJSオブジェクト取ってきたりJSの関数実行したりとかやるわけですね。GitHubひとまずここまでですー。(別のライブラリ)ちなみにこの記事の話題とは直接関係ないですが、jni層(.so)のロードにはfacebook/SoLoaderというのが使われているようでした。box.と書いてあり、どうやら再帰的に.soの依存関係を解決してくれるらしいです。へー何だそれどうなってんだ。いえばお久しぶりの投稿になりました。今後も気が向いた時にゆるく投稿していければと思います。NativeのAndroid版のJSブリッジはどうやってるの?Tweet広告を非表示にするもっと読むコメントを書く2016-11-24Bitriseをオープンソースプロジェクトで利用したい!最近Travisのワーカーが一部で不足しており、Xcode8.1をターゲットにすると、ビルドが始まるまで1時間待たされるなんてことがありました。これではちょっと回らないと思ったので、お試しでBitriseに乗り換えてみました。普段仕事では有料契約をして使っているので、問題ないだろう、と。Bitriseは、iOSとAndroidに特化したCI/Deliverlyサービス(PaaS)です。現状オープンソースで使うには以下の問題があることが判明しました。ビルド結果とログはオーナー及びメンバー以外は見れない。フリープランだとオーナーに対して2名しか登録できない。オーナーアカウントに対して2名までで、プロジェクトに対して2名までではない。2017.1.13追記:変更されたかもビルド自動再実行の機能がない。Travisだと、プルリクClose->Reopenでビルドが再スタートしますよね。(これもオーナーのアカウント単位)の制限があり、すぐに超過してしまいそう。超過分はFailedになります。これではコントリビュータが増えてくると使えないので、slackチャンネルで問い合わせてみました。すると、すぐに以下の回答がありました。追記:URLが変更になりました。機能リクエスト投稿しました。voteが足りず移行されなかったので、放置することにします。含まれる想定でいいのだと思います。OSSプロジェクトのビルド数制限解除なんと、言えば対応してくれるらしい!!!神!!!まとめ以上、速報でした。ちなみにBitriseのslack/emailのサポートは対応が神なので、もし何かわからないときは気軽に問い合わせてみると良いと思います。08:46Bitriseをオープンソースプロジェクトで利用したい!Tweet広告を非表示にするもっと読むコメントを書く2016-10-21GitHub開発時の複数リポジトリ横断の課題・ドキュメント管理についてGitHub開発時の複数リポジトリ横断の課題・ドキュメント管理について悩んでいます。現在のところ最善はこんな感じかしらと書いてみたので、ぜひコミュニティの皆さんのご意見をいただきたいな、と。ちなみに以前こんなのをQiitaに書きました。Qiitaこれまでの社内の標準的な運用は、Backlogで全て解決!です。社内のやり取りも対外のやり取りも基本Backlogですが、とりあえず社内の部分だけもう少し効率化したいなという状況です。Backlogではなくtracだ、とか色々あると思いますが、適宜読み替えていただければな、と。選定条件は、バージョン管理、編集中のロックもしくは同時編集ができることです。エクセルのマージとかしたくないですよね?gitを利用すると編集中のロックも同時編集もできないため、Subversionが良いのかな、と。いうわけでここはこれまで通りBacklogのまま。Flavorで書けるのがいいなーと模索中。あとは非プログラマでも編集できることが条件。wikiでもいいですが、部内横断的なWikiの場合、リポジトリ単位だと扱いづらい。今度これを試してみようと思っています。https://github.com/GitbookIO/gitbookまあここはこれまで通りBacklogでもそこまで生産性に影響するものでもないとは思っています。課題管理Backlogの課題機能は「通知機能がイケてない、jsの処理が重たい、障害頻度高い、カンバン形式にできない」というのが問題点。ボード上でプルリクがグリーンかレッドかが一目でわかるのは良さそうですけど。カンバン形式でGitHub連携が無料でできるのは、現時点ではwaffle.ioのみ。統合した課題管理ができます。https://github.com/waffleio/waffle.io/wiki/FAQs#multirepoよってwaffle.ioに軍配があがるかなと。追記Trelloの場合、リポジトリに権限がなくてもボードは閲覧できるので、何もしなくても1段階の権限管理ができると考えることもできますね。デザイン会社さんやテスト会社さんにも課題表だけは公開したい、ソースコードは公開したくないみたいな場合にも、Trelloなら気軽にそれができる、と。そのた正直言って、IaaSやSaaSでJIRAとかRedmine立てれば解決するような気もしています。あ、でもRedmineはプラグイン入れないとカンバンないか。Enterpriseでwaffle使えるのかと思って探したらこんなのを見つけました。takeout.waffle.ioできれば、エクセルもWikiもソースコードも一箇所でまとめて管理したいところですが、なかなか難しいものですね。Payが話題になっており、メルカリさんでは既に導入されたとのこと。あれ、そういえばアプリ外で課金させちゃダメなんじゃなかったっけ。この辺りのルールがよくわからん!となったので、調べてみました。結論から言うと、アプリ内で消費するコンテンツに関してはアプリ外課金ダメ。(IAP(アプリ内課金)使ってね)アプリ外で消費するコンテンツに関してはIAP(アプリ内課金)ダメ。