はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Amazonが、Certificate Managerを発表しました。 公式 AWS Certificate Manager 何ができるの？ AWSで使用するためのドメイン認証(DV)するSSL証明書を無料で作成できます。 ワイルドカードも、複数ホスト指定もいけます。さらに、自動で更新されます！！ メインサーバはEV証明書とか欲しいですが、ただ暗号化するだけならこれで十分そうですね。 テストサーバや、デモ用サーバも無料で暗号化できるので、SSLにしないのはエンジニアの怠慢になりますね。 既存の証明書をインポート すでに証明書を取得してい

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

該当バージョン iOS 9.0beta 9.0 9.0.1 9.1beta 1 10/4追記 どうやら、9.0.2で修正された模様。 詳細 iOS9系で時計がずれる問題が報告されています。 リストア時点ではズレなし、そこから毎日数秒ずつ時計が進むことが多い様です。 おそらく、iOSのバグだと思われますが、いつ修正が入るかわからないので対応が必要になるケースもあると思います。 タイムスタンプでユーザの不正行為を検証していたりすると問題になる可能性があります。また、ずれが大きい場合にはワンタイムパスワード認証に失敗する可能性が高いです。 確認方法 下記のページで、サーバ側の時計とクライアントの時計の差を表示できます。 http://www.nict.go.jp/JST/JST5.html また、標準の時計アプリの「世界時計」は秒針まで表示されます。 僕の手元で確認できている現象 ずれはちょっと

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

古き良き時代の答え 1ポイント = 0.35mm 1ポイント＝1ドット＝1ピクセルというのが大原則です。 ポイントがほぼ1/72インチであったことから、画面表示も72 dpi (dot per inch)にあわせて設計されました。これにより、画面にみたものと、印刷したものがほぼ同じになるという、WYSIWYGが実現されました。(What you see is What you get) 1インチは25.4mmなので、1ポイントは 1/72 inch = 0.35mmとなります。 iOS開発をしている場合の答え 1ポイント = 0.16mm 〜 0.21mm 画面サイズの多様化により、72dpiという前提は崩れ去りました。 Retina登場により、１ポイント=1ピクセルという前提は崩れ去りました。 iPhone6/6Plus登場により、1ドット=1ピクセルという前提も崩れ去りました。 Wha

Redhat発表 Shellshock: Bash Code Injection Vulnerability 見つかった脆弱性のCVE一覧 CVE-2014-6271 CVE-2014-7169 CVE-2014-7186 CVE-2014-7187 CVE-2014-6277 CVE-2014-6278 RedhatのErrataは、CVE-2014-6271向けと、CVE-2014-7169/CVE-2014-7186/CVE-2014-7187向けに公開されています。 CVE-2014-6277/CVE-2014-6278についても、最新のerrata適用後には問題は発生しないとのことです。 AWSの公式まとめ ALAS-2014-419 CVE-2014-6271/CVE-2014-7169/CVE-2014-7186/CVE-2014-7187/CVE-2014-6277/CVE

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

公式ドキュメント クラスクラスタ 一言で言うなら 抽象ファクトリを使った、 実装最適化 のためのテクニックです。 通常ファクトリパターンは、「同じインタフェイスで使える、 異なる振る舞い をする実装」を呼び出す場合に使われます。これに対して、クラスクラスタは「同じインタフェイスで使える、 同じ振る舞い をする実装」を呼び出すために使われます。 Cocoaにおけるデザインパターンの応用 Cocoaにおけるクラスクラスタの使用は、データ格納域が状況に応じて変化する可能性のあるオブジェクトの生成に限定されています。Foundationフレームワークには、NSString、NSData、NSDictionary、NSSet、NSArrayの各オブジェクトに対応したクラスクラスタがあります。

# import <Foundation/Foundation.h> @protocol BTKCoreData <NSObject> @property(strong,readonly,nonatomic) NSManagedObjectModel *managedObjectModel; @property(strong,readonly,nonatomic) NSPersistentStoreCoordinator *persistentStoreCoordinator; @property(strong,readonly,nonatomic) NSManagedObjectContext *managedObjectContext; @end @protocol BTKCoreDataProvider <NSObject> - (id<BTKCoreData>) get; @end

概要 NSObjectのカテゴリとして、「自分自身を引数にもつ」ブロックを呼び出すメソッドを作成しました。そのスコープ内では対象となるオブジェクトに好きな名前をつけられるので、特にUI関係のコードなどを非常に綺麗に書けるようになります。 説明よりも、下記サンプルを見るのが一番手っ取り早いです。 サンプルコード 通常の書き方 self.longNameLabel.text = @"test"; self.longNameLabel.font = [UIFont systemFontOfSize:15]; self.longNameLabel.textAlignment = NSTextAlignmentCenter; self.longNameLabel.numberOfLines = 3;

static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; SSLBuffer hashOut, hashCtx, clientRandom, serverRandom; uint8_t hashes[SSL_SHA1_DIGEST_LEN + SSL_MD5_DIGEST_LEN]; SSLBuffer signedHashes; uint8_t *dataToSign; size_t dataToSignLen; signedHashes.data = 0; hashCtx.data = 0; clientRandom.data =

segueの不満点 Storyboardのsegueはちょっとした遷移を書くのには便利なのですが、viewの状態遷移が複雑な場合にはあっという間にスパゲッティ状態になります。また、状態遷移にパラメタをつけたい場合、prepareForSegueを用いるのは結構面倒です。 実例 うちの会社で作っている「Poin」というアプリケーションの場合、「User」「Book」「Page」を表示するViewControllerに、様々な経路で状態遷移します。ざっと挙げても下記の通りで、実際にはこの倍近い経路があります。 Top -> Book Top -> User User -> Book User -> User Book -> User Book -> Page Page -> User Page -> Book Notification -> User Notification -> Book

なぜmixinが必要なのか？ ベースとなるViewControllerに共通の変数＋メソッドを追加したかった UIViewController UITableViewController UICollectionViewController カテゴリ＋AssociatedObjectでも出来なくはないけど、面倒。 実現方法 mixin定義をoptionalなprotocolとして定義し、それを実装するmixin用オブジェクトを定義する。 @protocol SampleMixinProtocol<NSObject> @optional @property BOOL aBool; @end @interface SampleMixin : NSObject<SampleMixinProtocol> @end @interface SampleViewController : UIViewCo

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

# include <sys/types.h> # include <sys/stat.h> # include <fts.h> - (void)traverseURL : (NSURL*) url fileBlock : (void (^)(FTSENT *entry))fileBlock dirBlock : (void (^)(FTSENT *entry))dirBlock { const char *cPath = [url.path cStringUsingEncoding:NSUTF8StringEncoding]; int l = strlen(cPath); char *path = calloc(l, sizeof(char)); strncpy(path, cPath, l); char * const paths[] = { path, NULL }; FTS* ft

Objective Cのブロックは非常に強力ですが、nilのブロック呼び出しを行うとEXC_BAD_ACCESSで落ちるという厄介な問題があります。blockにnilを与えること自体が不正に見えるかもしれませんが、Objective Cは言語仕様的にnilを許容するケースが多いので、nilを与えても落ちないように設計するべきだと思います。 チェックの方法にはいくつかのアプローチがあるのでサンプルを書いてみました。詳細はコメントをご覧下さい。 @interface BTKBlockNilCheck : NSObject - (void) runBlockSample1 : (void (^)(NSError *error))block; - (void) runBlockSample2 : (void (^)(NSError *error))block; - (void) runBlockS