個人的に一度は使ってみたい iOS開発 で使えるツールや技術 をまとめていきます 随時更新予定です C4 OSSのフレームワーク Swiftでクリエイティブコーディングを行う Demoビデオがありました インスタレーション的なアート作品とかつくってみたいです TIPS: クリエイティブコーディングとは： デジタルアート作品など、プログラミングでビジュアルを生成したり、データを可視化したりする技法 SwiftのEnumでログイン処理を簡略化 SNS連携ログインの簡略化をEnumを用いて実装する方法 Realmさんの記事に記載（他にもためになるポストがいっぱい） AWS Mobile Hub Amazon Web Serviceを使ったアプリの構築、サンプルプロジェクトを生成してくれる 選べるAWSの機能は、以下の6つ ユーザー認証（Cognito） アプリ分析（Mobile Analytic

About the content This content has been published here with the express permission of the author. Apps with only one login method limit user options and often lead to negative reviews, but with multiple login options comes great complexity. By using Swift enums, David East demonstrates how we can easily abstract it away to keep our view controllers and login logic clean and simple. Join him in thi

前提条件 push通知を行う際には以下の 内容を実行、完了済である必要があります。 AWS側 AWSのアカウントを持っていること AWSのSNSの設定が完了していること Swift側 AWSのSDKを導入していること AWSのSDKを使ってメソッドが利用出来ていること Rails側 既にRailsのアプリケーションをサーバーに配置済であること まだこのあたりを実行されていない方は以下の記事を参考に。 参考サイト SwiftでAWS SDKを使ってPush通知 Swiftアプリでも確認済み！RubyスクリプトとAmazon SNSで複数デバイスへのpush通知 バージョン Swiftのバージョン:1.2 Rubyのバージョン:2.1.5 Railsのバージョン:4.1.7 手順 1.GemファイルにAWSのgemを追加する gemの管理をしたいため Gemfile 参考サイト AWS SDK

iOS9でFacebookログインの実装方法のまとめです。 今回は画面にFacebookのログインボタンを表示する方法です。 Facebook　Developerへの登録とSDKのダウンロード Facebook　Developerでアプリを登録し、SDKをダウンロード。 info.plistの登録 Facebook　Developerで登録したFacebookAppID、FacebookDisplayNameをinfo.plistに追加する。 またLSApplicationQueriesSchemesを以下のように設定する。 framework追加 Facebook　DeveloperからダウンロードしたSDKから以下のframeworkをプロジェクトに追加する。 FBSDKCoreKit.framework FBSDKLoginKit.framework ViewControllerの実

original: The introduction to Reactive Programming you've been missing (by @andrestaltz) (translated by @ninjinkun, reviewed by @ma0e) あなたはリアクティブプログラミングと呼ばれる新しい方法が気になっている。 勉強するのは大変で、良い教材がないのでさらに難しい。私が勉強を始めたときは、まずチュートリアルを探した。見つけたのは一握りの実践的なガイドだけ、しかもそれらは表面をなぞっているだけで、リアクティブプログラミングのアーキテクチャ全体像を構築しようとしてはいなかった。ある関数を理解するのに、ライブラリのドキュメントは役に立たないことがある。 これを見て欲しい。 Rx.Observable.prototype.flatMapLatest(selector,

RxSwiftを用いるとHTTP通信まわりの記述をすっきりと書くことができるだけでなく、通信の実行スレッドを簡単に切り替えたり、レスポンスの処理をキレイに書くことができます。 通信のたびにスレッドに処理を割り当てたり、コールバック処理を型が合うように記述するのに苦労している方は是非RxSwiftを導入して、通信処理をラップしてあげるHTTPクライアントを導入してみると良いと思います。 HTTPクライアントのインターフェース さて今回実装するHTTPクライアントは以下のようなインターフェースです。 import RxSwift import Foundation public protocol HttpClient { func get(url: NSURL, parameters: [String:String]?, headers: [String:String]?) -> Observ

#import <AWSCore/AWSCore.h> #import <AWSS3/AWSS3.h> #import <AWSDynamoDB/AWSDynamoDB.h> #import <AWSSQS/AWSSQS.h> #import <AWSSNS/AWSSNS.h> #import <AWSCognito/AWSCognito.h> APNsのための証明書&ProvisiongProfile発行 続いてMemberCenterにて証明書を発行します。 AppIDの作成 まずはAppIDの作成から行います。 App Nameは適当な名前でも大丈夫ですが、Explicit App IDにはXCodeのBundleIdentifierと同様の値を入力します。 App Servicesのpush Notificationにも忘れずにチェックを入れます。 あとは流れに沿って作成します。

iOS の Push 通知用の証明書の作成ってめんどくさいですよね。年に一回とか新しいアプリを作る時にしかやらないので作る時には前回のことをほとんど覚えていなかったり。 でも今はfastlaneがあります。 fastlane はiOSアプリの開発に関するめんどくさい手続きを自動化してくれるツールセットです。 最近 Twitter社 の開発者用ツール Fabric の仲間入りをしたそうです。 参考：https://fabric.io/blog/welcoming-fastlane-to-fabric 準備 fastlane のインストール というわけでまず fastlane を導入します。 参考：https://github.com/fastlane/fastlane/blob/master/docs/Guide.md 手順は簡単で、 1. gem で fastlane をインストール 2.

概要 近頃、ReactiveのSwiftライブラリが沢山登場しています。 全部勉強してみて肌感掴んでおこうと思い、 下記の機能で同じアプリを作ってみて比較してみようと思いました。 https://github.com/naoto0822/try-reactive-swift 機能 APIリクエスト UITableViewで表示 引っ張って更新 (UIrefreshControl) スクロールでページング タップで詳細画面表示(SFSafariViewController) 今回は下記の3つでそれぞれ作ってみます。 RxSwift ReSwift SwiftBond Githubに公開してあります。 書き方がおかしかったり、上の機能が網羅できてないprojもあるので、ぜひPRお願いします。 https://github.com/naoto0822/try-reactive-swift それぞ

RxSwift勉強会＠Sansan に、はじめて「ブログまとめ枠」として参加しましたので、だいぶ遅くなって申し訳ございませんがまとめたもの公開します。 以下すでに先行して他の方がまとめたもの http://matome.naver.jp/odai/2146067615056021001 https://blog.ppen.info/wp/?p=357 http://blog.mogmet.com/rxswift-sansan/ またRxSwiftの予習が足りず、誤りがある場合はよしなに編集リクエストいただけると嬉しいです RxSwiftをプロダクトに導入してみた話 @kazu0620 Eightに導入した話 「さわったことある人、挙手」で参加者のうち多くの人が手を挙げていた模様（席の都合上良く見えなかった） 宣言的に記述できる => 「こういうものが流れてきて、こういう処理をする」というこ

iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴から情報設計の原則、それぞれ何のための部品なのか、という解説がされています。なぜこうなったのか、なぜこれが良くてあれが駄目なのか、Apple の UI デザイナーは何を考えてこのような設計にしたのか、HIG ではそのようなところまでは説明されていないことがあります。いくら内容を丸暗記したとしても「 なぜ 」がわからなければ本質から理解したとは言えません。 よくある UI デザインにおける誤り、『磨りガラス効果がかっこいい』『アニメーションしておくとかっこいい』『ボタンは右配置の方が押しやすい』『色が綺麗』『流行っているから優れている』…などがありますが、そういうことではない

パスワードを忘れた方はパスワードの再設定を行ってください。 初めての方ははてなID登録 (無料) してください。 うまくログインできない方はお問い合わせをご覧いただき、Cookieの設定をご確認ください。

Eureka EngineeringLearn about Eureka’s engineering efforts, product developments and more.

こんにちは。スマートデバイス開発チームの韮澤（にらさわ）です。 スマートフォンアプリの開発や開発標準の策定、技術推進などを行っています。 私の得意分野はiOS開発なのですが、iOSといえばSwiftの勢いが凄まじいですね。 私は先日try! Swiftカンファレンスに参加し、その盛り上がりを肌で感じてきたところです。 Objective-CからSwiftへ これまでiOS開発に使われてきたObjective-Cはその特殊な記法から、学習コストが高く開発を始めるための精神的な障壁が若干高めだったかと思います。 しかしSwiftの出現により、プログラミング未経験者はもとよりweb系エンジニアにとっても参入障壁がグッと下がった印象があり、社内でも「SwiftならiOSアプリを書いても良いかも」という意見が聞かれます。 そんな高まりを見せるSwiftの波に乗っていこう！ということでリクルートライフ

はじめに RSpecは難しい、よくわからない、といったコメントをときどき見かけます。 確かにちょっと独特な構文を持っていますし、機能も結構多いので「難しそう」と感じてしまう気持ちもわかります。 （構文については僕も最初見たときに「うげっ、なんか気持ちわるっ」と思った記憶がありますw） しかし、RSpecに限らずどんなフレームワークでも同じですが、慣れてしまえばスラスラ書けますし、実際僕自身は「RSpecって便利だな－」と思いながらテストコードを書いています。 そこでこの記事では、僕が考える「最低限ここだけを押さえていれば大丈夫！！」なRSpecの構文や、僕が普段よく使う便利な機能をまとめてみます。 具体的には以下のような構文や機能です。 describe / it / expect の役割 ネストした describe context の使い方 before の使い方 let / let!

今開発しているPlayer!で、チャット系のリアルタイム更新処理が必要となったので、色々調べています。 ※「スマフォアプリ」として共通事項が多いのでそう表記しましたが、基本的にスマフォアプリはiOSアプリとして書いてます。Android・Windows Phoneなどは差異があったり読み替える必要があると思っています。 結論 後半で詳しく書きますが、今のところ以下の結論に至りました。 PUSH通知に全て依存する構成でもそれなりに動く PUSH通知 + 双方向通信処理(WebSocketなど)の併用がベスト 双方向通信処理はPusher・Firebaseなどのサービスに頼る or ws・Socket.IO・SignalR + 対応クライアントライブラリなどで自前実装 Pusherなど有名サービスのクローンOSS導入も良さそうです stevegraham/slanger edgurgel/po

もう 3 月も終わりそうですが、本当に終われるのでしょうか... @riaf です。 突然ですが、ちょっとした静的なページを用意したいなっていうこと、わりとありますよね。 いつもはだいたい GitHub Pages (+Jekyll) とか使ったりすることも多いんですが、今回は簡単にテーマを編集したりしたかった (り、ブログのネタが欲しかったりした) ので、シンプルな作りで爆速な Hugo を使ってみることにしました。 最終的には、以下のような構成で動かそうという目論見です。 Github リポジトリに push CircleCI が Hugo でジェネレート IDCF クラウドのオブジェクトストレージ (S3 っぽいやつ) でホスティング CircleCI で Hugo を使うためにはまずインストールする必要があります。が、ここで go get とかしちゃうと負けた気持ちになるので、もっ

これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公

さてたまには PHP のことも書いてみようと思います。一応 PHP をメインにしている会社ですからね！ あ、申し遅れました @riaf です。 ところで、みなさん PSR はご存知かと思いますが、最近どうなってるか知っていますか？ (もう今更 PSR とは？みたいな話はしないぞ！！) あー、はいはい。PSR ね。あの autoload とかのやつでしょ。 とかいう認識だとちょー置いていかれる感満載の状態です。 軽くまとめてみましょう。(2016/02/29現在) STATUS NUM TITLE DEPRECATED 0 Autoloading Standard ACCEPTED 1 Basic Coding Standard ACCEPTED 2 Coding Style Guide ACCEPTED 3 Logger Interface ACCEPTED 4 Autoloading S