AWS LambdaのVPCアクセスに関して少しだけ解説 - Qiita
AWS LambdaのVPC内リソースへのアクセスが可能になるアップデートが行われました。これは昨年のre:Inventで発表のみされていたものの、その時点ではまだ使えず非常に多くの人がそのリリースを待ち望んでいた機能です。基本的な内容はこちらのブログ記事を参照頂くとして、ここではいくつかキーとなるポイントを簡単に紹介したいと思います。 概要 ブログを読んでもらえばわかるのですが簡単に説明すると、これまでAWS LambdaのファンクションはVirtual Private Cloud(VPC)内にあってパブリックなIPを持っていないAWSリソースにはアクセスできませんでした。従ってAWS Lambdaからデータベースにアクセスしようとした場合にはデータベースサーバのIPアドレスやポートをパブリックにした上でアクセスを許可する必要がありました。一方でAmazon ElastiCacheのよう
AWS Elastic Beanstalkを使ってParse Serverを簡単デプロイ！ - Qiita
注：本記事は個人によるものであり、所属する企業や団体に関係するものでも代表するものでもありません。 はじめに 先日、モバイル向けのバックエンドサービスであるParse.comが1年後に終了するという発表がされたのは記憶に新しいと思います。このニュースは多くの人に衝撃をもって受け止められました。 この発表のなかで、既存ユーザに対する救済処置としてデータベースの移行ツールとParse Serverのオープンソース化を発表しています。このParse Serverは発表中でParse APIとほぼ互換であるものであり、Node.jsで動くとしています。また、最新SDKでは自前のParse Serverへのリダイレクト機能が備わっているということですね。 というわけでこれをAmazon Web Services（AWS）で動かしてみたいと思います。AWSで動かすにあたって今回はAWS Elastic
RubyとAWSでつくるメディアストレージ基盤 - Qiita
概要 本基盤の果たす役割としては、「利用者が本基盤に向けてファイルをアップロードし、なんらかの(変換を含む)処理を行って利用サービス側に通知する」というものになる。 そこで、想定する利用イメージを大まかにでも理解してもらうため、抽象的なイメージを図示する。 ファイルをアップロードしたいユーザーは、まず本基盤の利用サービスに対してアップロード権限の発行を依頼する。 図では省略したものの、利用サービス側はその依頼を受けて、本基盤に対してアップロードチケットの発行を依頼し、取得した情報をアップロードしたいユーザーに対して返す。 アップロードユーザーはそれを受けて、本基盤に対してファイルのアップロードを行い、アップロード・バリデーション・変換が済んだものについては本基盤が利用サービスに結果を通知するというのが大まかな流れとなる。 次に、本基盤の持つ責務について簡単に解説したい。 本基盤は、メディア
iPhone6/iPhone6 Plusの画面対応について - Qiita
iOSにも画面フラグメントの時代がきました。 特にややこしくしているのが、iPhone6 Plusです。ピクセル比が3倍。 iPhone6 plusのiOSシミュレーターで画面のサイズをデバッグしてみると「414 x 736」になり、3倍すると「1242 x 2208」ですが、公称では「1080 x 1920」です。ということはピクセル比は正確には@2.46とかなのかな・・・。この辺りの仕組みがまだつかめてません。 既存プロジェクトの対応方法 iPhone6/6+のiOSシミュレーターで、既存のiOSプロジェクトを特に何もせずにビルド、実行すると「320 x 568」いわゆるiPhone5/5sサイズを拡大したような形で表示されます。（iPadでiPhoneアプリをx2で実行したような感じ。ただiPad⇔iPhoneほどの解像度の差は低いので、そこまで違和感は感じない。） iPhone6/
Swift開発でXcode6 Beta5にアップデートしたらたくさんコンパイルエラーになった - Qiita
Xcode6 Beta4 から Xcode6 Beta5にアップデートしたらいくつかコンパイルエラーになったのでメモしておきます。 init メソッドは override が必要になった • Overrides of a designated initializer must be marked with the 'override' modifier. (17892845 Does not implement its superclass's required members 以下を追加します。 required init(coder aDecoder: NSCoder!) { super.init(coder: aDecoder) } • The required modifier is written before every subclass implementation of a
Swiftで無限リスト - Qiita
を実装してみました。 https://github.com/dankogai/swift-lazylist 過去にも Perl http://blog.livedoor.jp/dankogai/archives/50839189.html JavaScript https://github.com/dankogai/js-list-lazy などでも実装していて、我ながらどれだけ Lazy List が好きなんだと思いますが、 Swiftのそれは格別に気持ちいいです。 以下、READMEから。 Infinite list let ns = lazylist { $0 } // infinite list of natural numbers println(ns.filter{$0 % 2 == 1}.map{$0 * $0}.take(10)) // [1, 9, 25, 49, 81,
ログ集計／時系列DB／可視化ツールの調査結果 - Qiita
近年、自分の中で集計／可視化は Fluentd(datacounter)+Growthforecast で定番化していました。 しかしプロダクトで新たに集計／可視化の要件が出てきたことと、 最近可視化ツール周りで 「Kibanaってなんじゃ？」「Graphiteってなんじゃ？」「InfluxDBってなんじゃ？」 など、このツール達は一体何なんだろう…？というのが前々から気になっていました。 今回良い機会なので ◯◯は何をするものなのか？ というのを一つ一つ調べてみました。 いわゆる「触ってみた系」の記事なので だいぶ浅い感じです。 大分類 大きく分けると、可視化ツールは以下の３つに分けられそうです。 ログ収集/集計 時系列DB（＋API）の担当。バックエンド側。 可視化部分の担当。 今回は バックエンド と 可視化部分 に焦点を当ててみます。 バックエンド 全文検索時エンジン+Restfu
Objective-C のコードレビューチェックリスト - Qiita
はじめに 本稿は Juri Pakaste 氏による Cocoa review checklist (commit fff5703)の翻訳です。他人の Objective-C のコードをレビューするとき注意する点、また普段のコーディングで心がけるべき点についてまとめられています。 なお、原文のタイトルは Cocoa review checklist となっていますが、内容が Cocoa に限らない範囲のトピックをカバーしているため、本稿のタイトルは「Objective-C の〜」としました。 誤訳の指摘や例の補足を歓迎します。 コードの見た目とコード以外の問題 不要な #import や @class 宣言を消す #import をソートする .m ファイルの中では、対応する .h ファイルの #import を最初の行に書く。空行をはさんで、ソートされた他の #import を書く。 X
認証局を立ててぼろもうけしたいんですが＞無理な理由を理解しよう - Qiita
SSLの認証局とか証明書とか勉強し始めはホント難いよね このへんのSSL/TLSの仕組みって勉強し始めの頃は凄く難しく感じるのよね。分かりやすく解説してくれてるサイトってあんま見たこと無いし。 んで、 >>300,304 みたいなことは僕も昔考えたことあったわー、と懐かしみを覚えたのでレスってみた。 証明書を発行できるかどうかは証明書のフラグで決まっている、という >>303 の指摘も重要よね。 以下2chスレより引用 丁寧過ぎると評判のレスをしてるID:UyEJo1f2が僕なわけだがｗ 2chだとそのうち倉庫に行っちゃうかもしれないのでここにメモ。 【認証局】SSLに関するスレ 2枚目【ぼろ儲け】 http://hayabusa6.2ch.net/test/read.cgi/mysv/1286532904/298-309 298 ：DNS未登録さん：2013/05/31(金) 13:31
A/Bテストよりすごい？バンディットアルゴリズムとは一体何者か - Qiita
オバマ大統領の再選に大きく寄与したことで大きな注目を集めているA/Bテスト。A/Bテストを導入した、することを検討している、という開発現場も多いのではないだろうか。 そんな中、Web上で次のような議論を見つけた。 20 lines of code that will beat A/B testing every time Why multi-armed bandit algorithm is not “better” than A/B testing 一言でまとめると「A/Bテストよりバンディットアルゴリズムの方がすごいよ」「いやいやA/Bテストの方がすごいし」ということだ。 で、バンディットアルゴリズムとは一体何者なのか？ そこでBandit Algorithms for Website Optimization (O'REILLY)を読んでみた。その結果分かったことを踏まえてざっくりと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Qiita
