GitHub:Enterprise 環境下では CocoaPods を 0.34.0 以上にアップデートしてはいけません

タイトルの地点で結構出落ちですが、本日少々厄介な問題にぶち当たってしまったので共有いたします。

発生条件

CocoaPods 0.34.0以上を使用し、GitHub:EnterpriseのgitリポジトリをPodSpecないしSourceリポジトリとして使用している場合に発生します。

発生する問題

CocoaPodsのgitを利用するアクションが全く成功しなくなります。具体的にはpod install, pod updateなどが全く通りません。

問題の原因

公式ブログにあるとおり、0.34.0以上からCocoaPodsは高速にgitリポジトリをcloneするため--depth 1 (shallow clone) オプションを採用するようになっています。しかしながらGitHub:Enterprise側の技術的問題なのか、GitHub:Enterprise内のgitリポジトリに対するhttpないしhttps経由でのshallow cloneが成功しないため永遠にpod installやpod updateが終わりません。

対処方法

• CocoaPodsを当面の間0.33.1のまま運用する。0.33.1を指定してインストールするときにはこちらのQiita記事が参考になります。
• http/httpsではなくssh clone URLを使用する。sshだと問題が起きないとの報告があります。GitHubに問い合わせてみたところやはりhttp/httpsのみで問題が発生するようです。
• ssh cloneがネットワーク上の問題などで使用できない場合、最後の回避策として:tagや:branchを使用しないで:commitを直指定するように社内のPodspecを書き直す。

根本的にはCocoaPodsかGitHub:Enterpriseかいずれかが修正されるのを待つしかありませんが、CocoaPods側としてはあまり積極的に対応する気がないようなので、GitHub:Enterprise側に対応を期待するしかないでしょうか。もちろん全てのGitHub:Enterprise環境下で発生するとは限りませんが、いずれにせよ注意する必要があります。

2014/10/01追記

GitHub:Enterpriseに問い合わせてみたところ、こちらは既知の問題であり現在修正中で、次のリリース時に修正されるそうです。次のリリースが社内環境にデプロイされるまでの辛抱ですね。

こちらからは以上です。

Swift から Core Data を操作するときはこの2点だけ気をつけよう (Xcode 6 beta 7編)

将来的にXcode側の対応が変わる可能性が極めて高いので暫定ですが、Xcode 6 beta 7でSwiftからCore Dataを触った時に注意するポイント2点まとめです。この2点にだけ気をつければSwiftでもCore Dataは案外あっさり動きますのでご安心ください！

1. プロパティの設定の仕方

• @NSManagedを使うこと
• Int, BoolではなくNSNumberを使うこと。StringはStringでOK
• Many関連にはNSSetを指定すること

2. entityNameの与え方

• コード上ではクラス名だけを与える
• Model Editor上ではモジュール名.クラス名（完全修飾名）を与える

Model Editorではこのようにモジュール名.クラス名の形で設定する必要があります

あとは普段Objective-Cで使っている時と同じように使えばOKです。一応、簡単なSwiftからCore Dataを操作するラッパライブラリを書いてみたので、もし宜しければ見てみてください。
https://github.com/akisute/Dove

【ヤヴァい】リリース直前の Swift の仕様が早くも悲惨なことになってる

正式版リリースまで後一ヶ月と噂されるXcode 6と新言語Swiftですが、リリース一ヶ月前にも関わらずその仕様が早くも悲惨との声がごく一部から上がっているようです！！

---

public private(set)って結局どっちなの！？

beta 5から追加されたアクセス制限指定子ですが、その仕様に疑問の声が！

https://t.co/Nkn0Yiz7Hn public private(set) var number = 0 // ゴッドキモい

— akisute (@akisutesama) September 5, 2014

なるほど、public private(set) var numberはキモいですね〜。ちなみにこれはgetterがpublicでsetterがprivateな変数の宣言のようです。なんかもっといい文法はなかったんでしょうか・・・

---

一行closureを使うときに注意！思わぬ落とし穴が！

スイフトさー、さんざんすでに言われてるかもしれないんだけど、返り値がVoidのclosureでさー { something in something.save() // let's say this returns Bool } ってやると返り値の型が違うって怒るのやめれ

— akisute (@akisutesama) September 5, 2014

更に糞なのは { something in something.save() // let's say this returns Bool something.save() // ditto } これはコンパイルエラーにならない。暗黙的returnは一行のときだけだから

— akisute (@akisutesama) September 5, 2014

これはSwiftの言語仕様上、実行コードが一行しかないclosureは暗黙的にreturnするものとみなされてしまうからのようです。これはちょっとひどいですね〜〜！

---

中には良い一面も・・・？

https://t.co/hzgpkhqHDw Nil Coalescing Operatorべんりだ、ドヤ顔で if let v = opt { return v } else { return "" } とか書かなくて済む

— akisute (@akisutesama) September 5, 2014

Nil Coalescing Operatorというのは ?? 演算子のことです。これは A ?? B のように使い、AがNot NilならAを、そうでなければBを返すという演算子です。なかなか便利に使えますよ！ちょっとはSwiftも見なおしたかも！？

---

おわりに

某まとめっぽくしたらなんかイマイチな感じになりました(´･_･`)
あとAppleふざけんな

Apple Push Notification で送られてきた通知を通知センターから消すたった一つの方法

いや、それがたった一つしか方法ないのはさすがにどうかと思うのですが。

皆さんもiOSのアプリを使っていて、通知を受け取った後にアプリを開いても通知センターから通知が消えず地味にイライラする現象に見舞われたことがあるのではないかと思います。私もお恥ずかしながらつい最近知ったのですが、実はこれアプリ側で何も対応しないと通知センターから通知は消えません。それどころかなんと通知センターからプッシュ通知を消すためのAPIも一切提供されていません。つまり普通にアプリを作ると通知センターから通知が消えないのです。Appleふざけんな

※注記: ここで私が消せない通知と呼んでいるものはApple Push Notification経由でのRemote Notiifcationです。UILocalNotificationは自由自在にアプリ側から消せるので、適切なタイミングで消してないのは単なる実装者の怠慢となります。

しかしながらTwitterやFacebookアプリはきちんとアプリが開かれたタイミングで通知センターから通知が消えるようになっています。不思議です。そこでちょっと調べてみました。

解決策

以下のリンク先にあるように、一度applicationIconBadgeNumberを1以上の数字に設定してから、0に戻すと、全てのApple Push Notification経由での通知が消えるようです。

http://stackoverflow.com/questions/8682051/ios-application-how-to-clear-notifications
http://stackoverflow.com/questions/9925854/remove-single-remote-notification-from-notification-center

iOS 5~8のすべてのバージョンで動作することを確認しています。少々ダサいですがこの方法でしのいでいきましょう！

※注記: 個別に通知を消す方法はありません。なおiOS 8より、ユーザーが直接通知センターから通知をタップしてアプリが起動した場合のみ、タップされた通知が自動的に消えるように仕様が変更されています。相変わらずアプリから明示的に消すことはできません。Appleふざけんな