天に運を任せるように。 WWDC16 をきっかけにして、初めての海外 San Francisco の地を訪れてきました。
そんな中、利用させて頂いている仮想サーバー ConoHa に ConoHa API なる Web API があることを知りました。 ドキュメントを読む限り、請求データの取得とか、VM の操作とか、いろいろできるらしくて面白そう。これは ConoHa API を学んでみるにも、気になっていた Himotoki を学んでみるにも、良い機会そうに思えてきました。 そんな気持ちを後押しするもうひとつに、@_ishkawaさん の APIKit というライブラリがありました。 このライブラリは、単純ながらも何かと手間がかかりがちな Web API へのアクセス周りをシンプルかつ的確に記述できるライブラリです。しかもこちらも「型安全」を特徴にしていて、さらには Himotoki と相性が良いとのことで、Himotoki に興味を惹かれるにつられて、興味が湧いていたのでした。 せっかくなので、ConoH
private アクセスコントロール指定子private は、同じファイルからだけのアクセスが可能なオブジェクトに指定します。 ファイル内であれば、あるクラス内で定義したprivate な値に、ほかの異なるクラスからでもアクセスできるので、たとえば『ある値を保持するクラス』と『そのクラスの値をセットするパーサークラス』を作りたいときなどに便利です。 値を保持するクラスの中身は外部から変更させたくないけれど、その値をセットするパーサー機能を別のクラスに任せたいときでも、値をセットするメソッドやプロパティをprivate で実装しておいて、同じファイル内でパーサークラスを実装すれば、それらを外部に公開することなく、パーサークラスが自由に値クラスを操作できます。 internal アクセスコントロール指定子internal は、同じモジュール内でのアクセスが可能なオブジェクトに指定します。 モジ
Apple Watch のマップアプリでナビ機能が使えるようになってますけど、それだけを頼りに目的地までたどり着けるものなのか、実際に確かめてみることにしました。
全く同じメソッドが、複数のプロトコルから既定の実装として与えられている、要は「曖昧な実装になっている」ため、どれを呼び出したら良いのかがわからないということを主張しているのでしょう。 そしてこのとき面白いのが、構造体 Picture を両方のプロトコルに準拠させようとしているところで、不可思議な次のビルドエラーが発生します。 既定の実装だけしかないのに、なぜ両方から「準拠できていない」と指摘されているのか。 これを見させてもらった最初は「Protocol Extension ってまだまだ甘い実装なのかな」と思ってみたりもしたんですけど、それからゆっくり考えていたら、なんとなく Swift の気持ちが分かってきました。 エラーの理由は曖昧性 まず、そもそもの大事なポイントなのですが、既定の実装を extension で添えるに当たって、その機能のシグネチャを protocol に宣言しておく
新緑も色づき始めた 2015-05-16 に、横浜馬車道のI.S.O 横浜 でyidev 第19回勉強会を開催しました。 自分が主催を引き継いでからこれで 4 回目、人に恵まれなんとか無事にここまで開催を続けることができました。今回もまた新しい顔ぶれも加わって、おかげさまで楽しい会になりました。 yidev 第19回勉強会 : ATND 開催目線での振り返り 今回もまずは開催の目線で会を振り返ってみます。 会場準備 使わせて頂いている会議室は、基本はこのような机の並びになっています。 これを並び替えて使っているのですけど、どうしても机の配置が窮屈になってしまっていました。 これまで数回開催して行く中で『少しでも余裕を持った配置にできたらいいな』と思いながら過ごしていたのですけど、前回と前々回に少し早めに来られて準備を手伝ってくれた吉川さんと八十嶋さんによって素晴らしいアイデアが生まれました
2015-03-07 に、横浜馬車道のI.S.O 横浜 でyidev 第18回勉強会を開催しました。 自分が主催を引き継いでから、今回が 3 回目の開催です。 ようやく勝手が分かり始めてきたのか、準備まわりは相変わらず何かと手間取りますけど、始まってしまいさえすれば、いくらか気分に余裕を持って進められるようになってきたようにも思えます。 今回は集ってくれた活気と好奇心に溢れるみんなに恵まれ、かつてないほどの朗らかな賑わいの中で、この上なく楽しい会になりました。 発表者も参加者も今回はいつにも増してかなりなハイレベル揃い、これほどの高度な話題で和気藹々と団欒できるなんて素晴らしいことですね。自分だけでは到底創り出せない時間を体験させてもらえて幸福でした。 yidev 第18回勉強会 : ATND 開催視点での振り返り さて、今回もまずは開催の視点から会を振り返ってみます。 時間不足 前回の開
2014-09-27 に、横浜馬車道のI.S.O 横浜 でyidev 第16回勉強会を開催しました。 yidev 第16回勉強会 : ATND これまでは@cocoponさん が主催を務めていましたが、今回から自分が引き継がせて頂けることになりまして、今回がその第1回目ということになります。 そこで今回は自己紹介として、簡単ながら勉強会の紹介も兼ねて、次のスライドを作ってオープニングで使わせて頂きました。 ちなみに@cocoponさん はyidev の2代目の主催者になります。初代主催者は@takayamaさん で、このお二方によって、今この瞬間までのyidev が大切に築き上げられてきました。 好きな言葉 今回の勉強会を準備するにあたり、これまでのyidev のこれまでを振り返ってみていたのですけど、そんな中でとても心に留まる言葉を見つけました。 講習会じゃないからね :D この言葉は横
Objective-C には @synchronized という、複数スレッドからの同時アクセスをブロックする排他制御を行う仕組みが用意されています。 この @synchronized ディレクティブでは、引数に指定した Objective-C インスタンスをキーにして、他からの同時アクセスをブロックしたり、他がブロックを解除されるのを待ったりできます。 これと同等の排他制御として ミューテックス があります。 他にも セマフォ、@property の atomic キーワード、NSLock、NSRecursiveLock などが利用できます。 クリティカルセクションを保護する 同時アクセスされたくない個所を、キーとして使う Objective-C インスタンスを引数にして @synchronized で括ります。 引数に渡すキーには self も使えるので、クラスインスタンス全体で 1
iOS 7 からデザインコンセプトが変更されて、同じレイアウトの画面を iOS 6 と iOS 7 とで表示させたときに、実際のレイアウトがずれる場合があります。 そして Xcode 5 では、その違いを埋める方法として iOS 6/7 Deltas という設定項目が用意されました。 例えばステータスバーの存在の違い たとえば iOS 7 環境では、ステータスバーが原則的にルートビューに重ねて表示されるようになりました。 これは iOS 7 のレイヤーを重ねる発想とコンテンツを大事にコンセプトに依るもので、ステータスバーなどにも透明感を持たせ、その下のコンテンツの存在感を示すのには不可欠な存在です。 ただ、iOS 6 と iOS 7 両対応の画面をデザインするとき、見た目だけでなくて座標も変わってくるので注意が必要です。 iOS 6 ではいちばん上を Y=0 でレイアウトすればいいのは変わ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く