はてなブックマーク

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

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

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

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

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

リファクタしていると、このメソッド名やばい変えたいという気持ちが高まるケースが多々あると思います。 そんなの、 徹底的にgrepすればいい し、 テスト書いてるだろ？ って話なんですが、特に後者に対して「お、ぉう」となるケースがありうると思っていて、「このメソッド名変えたら誰か困る人がいるかもしれない。。。」という気持ちにより、心が折れるのはつらいですよね。 alias_methodでとりあえず逃げる事もできますが、あとでリファクタしたいよねというケース。 そんなときは、こんな感じでwarningを出す事があるかなーと思っています。

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

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

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

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

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

ほら、 Facebook の canvasアプリ やら page tabアプリ やら作る時って、 iframe にサイトを表示させるじゃないですか。 そうすると、 3rd party cookie について 思いを馳せないとならんわけですよ。 普通に、 OAuth すると、facebook の iframe x-frame-options のセキュリティー・ポリシーにより、画面が遷移しない。 ここで、なぜ自分の作ったFacebookアプリが facebook の iframe x-frame-options のセキュリティー・ポリシーにかかるかというと、Facebook ページタブ内のページは facebook のプロキシ介しているんですね。 なので、そういう事が起こる。 ではどう対応するかと omniauthの iframe オプションで回避 これだと top の window で OA

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

require 'rubygems' require 'open-uri' storage = Fog::Storage.new( provider: 'AWS', aws_access_key_id:ENV['AWS_S3_KEY_ID'], aws_secret_access_key:ENV['AWS_S3_SECRET_KEY'], region: ENV['AWS_REGION'] ) bucket = storage.directories.get(ENV['AWS_S3_BUCKET']) bucket = storage.directories.create(key: ENV['AWS_S3_BUCKET']) unless bucket path_to_save = 'users/images/hoge2.png' image_url = 'http://a0.twimg.

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

Railsにおける RESTfulなURL設計 勉強会で、RESTful APIとしてのRailsとクライアントとしてのJavaScriptというお話をさせて頂きました。 その際に、@tkawaさん、@t_wadaさん、@moroさんのお話を聞いた後に考えたことをまとめておきます。 RESTful APIとしてリソース設計する際に、あまりにもRailsのmodel = ActiveRecordという考えにとらわれ過ぎると何でも非同期処理で取得したくなってしまうのでよろしくないということ。 非同期処理でユーザーの体験を良くしようとするつもりが逆に体験を悪くしていては本末転倒であるということ。 非同期処理でもn+1問題に気をつける どうしてもリソースをActiveRecord単位のmodelで分割していると非同期処理で全てを解決しよう考えがちです。 例えば、私の考えた例ですと、/groups/

RailsにおけるRESTfulなURL設計勉強会 千駄ヶ谷.rb #12 #sendagayarb にて発表予定の記事です。 よくあるAjaxを利用したページの例 Sedndagaya.rbというグループへ投稿出来るサイトがあるとします。 この時、グループのページにアクセスすると、グループの詳細情報と、グループへ投稿された記事が表示されます。 このとき、大きく分けて3つの描写が行われます。 通常のリクエストに対するレスポンスの描写 非同期のリクエストに対するレスポンスの描写 DOM要素のイベントに対するレスポンスの描写 その時の流れは以下のようになります。 エンドユーザーがあるURIをブラウザ経由でアクセスする。 たとえば、 http://example.com/groups/1 にHTTP GETリクエストを送信してアクセスする。 Webサーバー(アプリケーション・サーバー)が対応する

window.App = Models: {} Collections: {} Views: {} Routers: {} init: (options)-> options = {} unless options options.pushState = true options.hashChange = false # don't want to rewrite /pathname to #pathname # override getHash # this can fire backbone router when url doesn't has hash fragment Backbone.history.getHash = -> if window.location.search search = window.location.search else search = '' re

このエントリーはGitアドベントカレンダーの15日目です。 今回紹介するコマンドは、基本的には反則技と言われる事が多いです。一人プロジェクトにおいて自己責任で利用するコマンドと考えた方が良いと思います。複数人で管理しているプロジェクトで実行すると、色々困った事になる事が多いです。私は、一人プロジェクトにおいてremote reposigitoryをbackupとして位置づけている場合に利用する事が有ります。 git commitしたあとに直前のメッセージの変更やcommit内容の変更を修正する際には git commit --amend をします。 もっと過去の歴史を書き換えたい場合はgit rebase -iというコマンドで書き換える事が可能です。 しかし、すでにgit pushした後に上記のようにcommit内容を修正してもremoteとlocaleのrepositoryに不整合が生じ

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

iOSアプリを開発していて、FacebookなどのOAuthを利用しつつ、自社のweb apiにアクセスする際の認証・認可の方法を考えています。 具体的にはpinterestはfoursquareなどと同様の仕組みです。 解決策 数人で考えてみました。 1. 自社の web api 認証にOAuth providerのuid, tokenを使いまわす （その場に居た人が大きな声では言えないが、こうしていると言ってていて「それやばいっしょ」って話になったのであえて解決策の1に挙げてますがダメなやつ） 自社の web api でユーザーのヒモ付をOAuth providerのuid, 初回に発行されたtokenで行う token はしっかり守っていないといけないのでは？ 本来、OAuth provider 認可に利用するtokenを自分のweb api認証・認可に使いまわすのはだめじゃない？

@import "twitter/bootstrap"; // import responsive layout @import "twitter/bootstrap/responsive"; // Your custom stylesheets goes here (override Less here) @media (min-width: 980px) { body { padding-top: 60px; } } @black: #000000; @grayDarker: lighten(@black, 16%); @grayDark: lighten(@black, 32%); @gray: lighten(@black, 48%); @grayLight: lighten(@black, 64%); @grayLighter: lighten(@black, 80%); @wh

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

色々と手順はよく見かけるのですが、各手順やファイルの意味が分からなかったので 自分なりに調べてまとめてみました。間違いあればコメントにてご指摘下さい。 秘密鍵(Private Key)と公開鍵のセット(Public Key) チーム開発時は開発用、配布用で分けるとよい。個人でも分けておくと後で楽。 それぞれ、以下のキーチェーンからのCSR作成時に自動で出来上がりキーチェーンアクセスに記録される。 別の開発マシンで使う際やSaaSでPush通知する際などには、下記*.cerから*.p12ファイルとして書き出して、何らかのセキュアな方法(オススメはUSBとかなの？)で別マシンに移す。 証明書要求（Certificate Request or Certificate Signing Request）(いわゆるCSR) キーチェーンアクセスから作成する。 デフォルト名はCertificateSig