logo

Support your social media marketing & Big data analyzing.


IE9でtwitter bootstrapのgradientが変な色になる

ただいま、開発の真っ最中。
例のごとく画面系はTwitter Bootstrapにお世話になっています。

さて、そのTwitter Bootstrapでのバグ?というか、はまったのでメモしておきます。

bootstrapではnavbarというクラスがあり、縦にも並べられるので、メニュー等に利用できます。

このクラスを利用して、メニューの色を独自に変えようとしたところ、マウスオーバーしたときの色が指定したのと違う。しかもIE9だけ。。。

書いていたCSSはこんな感じ。

.nav-list > li > a:hover {
	zoom: 1;
	color: #333;
	background-color: #ddd;
	background-image: -moz-linear-gradient(top, #eee, #ddd);
	background-image: -webkit-gradient(linear, 0 0, 0 100%, from(#eee), to(#ddd));
	background-image: -webkit-linear-gradient(top, #eee, #ddd);
	background-image: -o-linear-gradient(top, #eee, #ddd);
	background-image: linear-gradient(to bottom, #eee, #ddd);
	background-repeat: repeat-x;
	filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#eee', endColorstr='#ddd', GradientType=0);
	-ms-filter:"progid:DXImageTransform.Microsoft.gradient(GradientType=0,startcolorstr=#eee, endcolorstr=#ddd))";
}

全く持ってIE9だけ発生する理由が分からないので、まずは!importantを付与。
それでもだめ…orz

理由がわからんので、さっそくgoogle先生経由でstack over flowでそれらしき記事を発見。

結論から言うと、#dddではなくて#ddddddと書かないとこうなるということでした。
それで下記のように修正したらなおりました。

.nav-list > li > a:hover {
	zoom: 1;
	color: #333333;
	background-color: #ddd;
	background-image: -moz-linear-gradient(top, #eeeeee, #dddddd);
	background-image: -webkit-gradient(linear, 0 0, 0 100%, from(#eeeeee), to(#dddddd));
	background-image: -webkit-linear-gradient(top, #eeeeee, #dddddd);
	background-image: -o-linear-gradient(top, #eeeeee, #dddddd);
	background-image: linear-gradient(to bottom, #eeeeee, #dddddd);
	background-repeat: repeat-x;
	filter: progid:DXImageTransform.Microsoft.gradient(startColorstr='#eeeeee', endColorstr='#dddddd', GradientType=0);
	-ms-filter:"progid:DXImageTransform.Microsoft.gradient(GradientType=0,startcolorstr=#eeeeee, endcolorstr=#dddddd))";
}
うーん、やっぱりIE早く死んでほしい。

このエントリーをはてなブックマークに追加

ウィジー村山です。

Webサーバ以外のサーバに対してjQueryを使って手軽にAjax通信をしたいということありますよね。

弊社ではAPIサーバを別ドメインで構築して、WebサーバからAPIサーバにアクセスするという形を取るアプリを作りました。

そこでAjaxを試してみるとChromeで怒られます。

AjaxはXMLHttpRequestを利用して通信しているのですが、W3Cで決められているようで、XMLHttpRequestの呼び出しは、同一ドメインからしかできないようになっているとのこと。 http://www.w3.org/TR/cors/

なので、APIサーバ側にちょっとした工夫をしてやる必要があります。 WebサーバがApacheなら.htaccessに下記の記載を入れます。

Header append Access-Control-Allow-Origin: *

これでどこからでもアクセスできるようになります。 接続元を限定したいのであれば * を特定のドメインに変えればいいです。

よっしゃ成功と思ったのもつかの間、IEで怒られます。
Ajaxの返り値を見てみるとそもそもjsonじゃないし…。

これまた調べてみると、IEはXMLHttpRequestではなくXDomainRequestを利用しており、さらにjQueryはXDomainRequestに対応していないとな…。 そりゃ怒られるわけだ。

ブラウザ判定して普通のAjaxを書かなくてはだめか…と思っていたら見つけた素晴らしいjQueryライブラリ。
これを読み込むとIE8でもIE9でもjQueryで別サーバーとajax通信できるようになります。
その名もxdr.js!!

下記のURLでGETできます。
https://github.com/tlianza/ajaxHooks/blob/master/src/ajax/xdr.js

このエントリーをはてなブックマークに追加

an unexpected error has occurred…

はじめまして ウィジーの小黒です。

S3のファイル削除ではまったのでメモしておきます。

S3内に無駄なファイルがだいぶたまっていたので、ちょっと整理しようと思ってポチポチとファイルを削除してました。

ポチ・・・・Done

( ^ω^ )

ポチ・・・・Done

( ^ω^ )

ポチ・・・・an unexpected error has occurred

( ゚д゚)

謎のエラーが・・・。何これ。僕何にも悪いことしてないのに。

とりあえずGoogle先生に助けを求める。すると・・・。

s3cmd fixbucket s3://bucket/削除したいファイルORフォルダ

ってのが有効らしいって事がわかった。なんかファイルの名前がおかしかったようで、それを全部直してくれるらしい。

さっそくコマンドプロンプトからs3cmdコマンドで上記命令を実行

なんかめちゃくちゃいっぱい意味不明な文字が出てくる。よくわかんないけど、なんかちゃんと動いていてくれそうだ。

実行が終わった後にもう一回削除してみる。

ポチ・・・Done

ヽ(・∀・ )ノ

というわけで、無事削除できました。

後で知ったのですが、s3cmdコマンドの使い方見れば載ってたみたいです。ちゃんと読まなきゃな・・・。

このエントリーをはてなブックマークに追加

Twitter SearchAPI 1.0と1.1の比較

ウィジーの早川です。

今回はウィジーで運用しているTwitterのSearchAPIを使ったシステムをver1.1に対応させる際にver1.0と1.1の差異について調べたのでその結果をアップしようと思います。

以下がSearchAPIのver.1.0とver1.1の使用出来るパラメータを比較した表です。

SearchAPIへのリクエストに使用出来るパラメータの対応表

比較するパラメータ ver.1.0 ver.1.1
q 必須パラメータ。 検索したい語句を指定する。 フォーマットはURLエンコードされた状態で140字以内。クエリも使用可。 必須パラメータ。 変更点は使用可能な文字数が140字から1000字になったこと。
callback コールバック関数名を指定する。 formatにjsonを指定したときのみ使用可能。 ver.1.1ではjson形式のみなのでformatを意識する必要がない。
lang 検索対象となる言語を指定する。 指定方式はISO639-1に準拠。 ver.1.0から変更なし。
rpp / count ver.1.0では”rpp”を使用。 一回のリクエストで最大で取得する件数を指定。 指定可能範囲は1~100 デフォルトは15。 ver.1.1では”count”を使用する。
page ページ番号の指定。 これは上記のrppで指定した件数単位で1回あたりに取得できる件数を1ページという単位で区切ったもの。 rpp*pageで取得できるのは最大1500件。 なお、連続で取得した場合常に最新の状態が変化するためデータが重複したり、逆に取りこぼすデータがあるよう。 ver.1.1にはページ概念がなくなったため、取得したjsonの”next_results”からパラメータを取得することで遡って取得することができる。
max-id 検索結果の内指定したIDよりも小さなIDのツイートのみを取得するように指定できる。 ver.1.1では指定したIDのツイートのみを取得することもできるらしい。
since_id 検索結果の内指定したIDよりも大きなIDのツイートのみを取得するように指定できる。 ver.1.0から変更なし。
until 検索結果の内指定した日付より前までのツイートのみを取得するように指定できる 形式は[YYYY-MM-DD] ver.1.0から変更なし。
geocode 検索範囲を指定できる。 指定形式は[緯度・経度,半径(マイルまたはキロメートル単位で指定する)]。 この指定はGeotaggingに対応したAPI経由で取得したものになるらしい。 ver.1.1では指定の形式が以下のように変更になった。 [緯度,経度,半径]
show_user ツイートの冒頭に「ユーザー名: 」を付与するかを指定する。 trueで付与,falseで付与しない。 ver.1.1には存在しない。
result_type 検索結果の集計方法を指定する。 指定値は以下の3つとなる。        recent: 新しいツイートを優先して取得する。 popular:人気度の高いツイートを優先して取得する。(公式RTされてるものほど「人気が高い」ものとして扱われるらしい)。 mixed:recentとpopularの両方を適度に取得する。 ver.1.0から変更なし。
locale ver.1.0には存在しない。 qでリクエストしたクエリの使用言語を指定します(現在は ja のみ有効)。 これは言語特有のクライアントのための機能で、大体はデフォルトで(指定しなくて)問題ないようです。 例) locale=ja (使用言語を日本語に設定)
include_entities ver.1.0には存在しない。 Tweet entitiesを結果に含めるかを指定します。 現状ではtrue・falseどちらを指定しても追加される項目などは確認できませんでした。 Tweet entitiesは1.0ではREST系APIのみに提供されていた値のようで、ツイートの内容に含まれるURL やハッシュタグ、メディア (画像などの URL?) などの情報が含まれている場合、それらをtwitter 側で解析した情報を提供してくれるようです。 true,falseで指定します。 デフォルト値はtrue。

このような使用の変更から一定量のデータを連続で取得するためにはver.1.0ではrpp×pageを指定することでデータを取得出来ましたが、 この方法をとっていた場合ではver.1.1ではリクエストの取得結果から”next_results”を取得してパラメータに入れる必要があるようです。
“next_page”を使って次のページを取得していたのであれば”next_results”に置き換えれば大丈夫だと思います。

また、ver.1.0で取得できていたパラメータと対応するver.1.1のパラメータの一覧では以下のようになります。

SearchAPIから取得できるパラメータの対応表

ver.1.0 ver.1.1
json->completed_in json->search_metadata->completed_in
json->max_id json->search_metadata->max_id
json->max_id_str json->search_metadata->max_id_str
json->next_page json->search_metadata->next_results
json->page json->search_metadata->count
json->query json->search_metadata->query
json->refresh_url json->search_metadata->refresh_url
json->results->*(number)->created_at json->statuses->*(number)->created_at
json->results->*(number)->from_user json->statuses->*(number)->retweeted_status->user->screen_name
json->results->*(number)->from_user_id json->statuses->*(number)->retweeted_status->user->id
json->results->*(number)->from_user_id_str json->statuses->*(number)->retweeted_status->user->id_str
json->results->*(number)->from_user_name json->statuses->*(number)->retweeted_status->user->name
json->results->*(number)->geo json->statuses->*(number)->geo
json->results->*(number)->id json->statuses->*(number)->id
json->results->*(number)->id_str json->statuses->*(number)->id_str
json->results->*(number)->iso_language_code json->statuses->*(number)->metadata->iso_language_code
json->results->*(number)->metadata->result_type statuses->*(number)->metadata->result_type
json->results->*(number)->profile_image_url json->statuses->*(number)->user->profile_image_url
json->results->*(number)->profile_image_url_https json->statuses->*(number)->user->profile_image_url_https
json->results->*(number)->source json->statuses->*(number)->source
json->results->*(number)->text json->statuses->*(number)->text
json->results->*(number)->to_user json->statuses->*(number)->in_reply_to_screen_name
json->results->*(number)->to_user_id ver.1.1には存在しません
json->results->*(number)->to_user_id_str json->statuses->*(number)->in_reply_to_user_id_str
json->results->*(number)->to_user_name ver.1.1には存在しません
json->results_per_page ver.1.1には存在しません
json->since_id json->search_metadata->since_id
json->since_id_str json->search_metadata->since_id_str

注意点
1 *(number)には取得した各ツイートの番号が振られます。小さいほどmax_idが大きいです。
2 ver.1.1のjson->statuses->[number]->retweeted_status項目はリツイートされていないツイートには存在しないので注意してください。

ver.1.1ではリプライされたツイートIDをSearchAPIから取得できたりと、 取得可能なパラメータがver.1.0に比べて格段に多くなりました。

実際にver.1.1のSearchAPIから取得したサンプルのjsonがTwitterのディベロッパーページにあるので参考にしてみてください。
https://dev.twitter.com/docs/api/1.1/get/search/tweets

このエントリーをはてなブックマークに追加

February 2013 Breaking Changes

村山です。

2/4にFacebookの開発者アカウントにアラートがでました。

な、何?緊急修正だと?

image

ということでさっそくググって、他のブログを参考にダッシュボードの詳細設定からFebruary 2013 Breaking Changesのラジオボタンを有効に変更。

image

なんだ、この変更だけなら楽勝だぜ、と思ったのもつかの間、アプリからFacebookログイン機能を使ってログインしようとしたら、下記のようなエラーが発生。。。

image

えっ、これだけじゃダメなの?他にやり方書いてないよ。。。

ということで英語の詳細説明を読むハメに。

で、わかったのがどうやら

Authenticated referrals going away 
We will remove the Authenticated Referrals feature. You should instead use the Login Dialog.

という部分に抵触しているようだ。

Authenticated Referralsって何よ?

で、結果として接続先のURLの変更で解決したのでメモっときます。

(変更前)

header('Location: https://graph.facebook.com/oauth/authenticated/authorize'
	. '?client_id=' . $client_id
	. '&redirect_uri=' . urlencode($redirect_uri)
	. '&state=' . $sess->state);

(変更後)

header('Location: https://graph.facebook.com/oauth'
	. '?client_id=' . $client_id
	. '&redirect_uri=' . urlencode($redirect_uri)
	. '&state=' . $sess->state);

でも、アラートでてから修正まで2日ってちょっと短かすぎないか。

3月と4月にも修正あるから気をつけよう。

このエントリーをはてなブックマークに追加