adbコマンドを使えるようにする
1)Android Developersのサイトにアクセスしページ内[Download the SDK]をクリックします。
Android SDK | Android Developers
SDKとは Software Development Kit のこと、ソフトウェア開発に必要なものがセットになっているものの総称です。
2)利用規約書への同意を求められるので同意し、利用しているWindows環境を選択し[Download the SDK Bundle for Windows]をクリックします。
利用しているPCが32bitか64bitかわからない場合は、以下のリンク先を参考に確認してください。
Microsoftサポート:自分のパソコンが 32 ビット版か 64 ビット版かを確認したい
3)適当な場所に保存し、保存されるZIPファイルを展開します。
4)展開され作成されたフォルダの中でadb.exeがある場所を確認します。
私の場合、展開されたフォルダの名前が「adt-bundle-windows-x86-20140321」でそのフォルダ内の「sdk」フォルダの中にある「platform-tools」フォルダの中にadb.exeがありました。
5)adb.exeを右クリックし「プロパティ」を表示し、「場所」を確認しコピーします。
私の場合は、以下のとおりのパスになりました。
C:\Users\trippyboy\Documents\adt-bundle-windows-x86-20140321\sdk\platform-tools
6)コマンドプロンプトを起動します。
キーボード上のにあるWindowsのロゴが書かれた「Windowsキー」と「R」を同時に押し、「ファイル名を指定して実行」を表示させます。入力欄に「cmd」と入力してEnterをおすとコマンドプロンプトが起動されます。この操作が難しい場合は、スタートボタン⇒すべてのプログラム⇒アクセサリ⇒コマンドプロンプトから起動できます。
7)上記5で確認したディレクトリ配下のコマンドを実行できるように以下のコマンドを実行します。
>set path=%path%;C:\Users\trippyboy\Documents\adt-bundle-windows-x86-20140321\sdk\platform-tools
「%path%」というのは、Windowsの中のどこ(パス)に実行可能なコマンドがあるかを収めているもの(環境変数)で、それが「;」区切りで設定されています。そこに一時的にadb.exeがあるパスを追加してあげるのがこの「set path=%path%;上記5で確認したパス」になります。この一時的なパスの追加はコマンドプロンプトを閉じた時点で元通りになります。
設定したpathは以下のコマンドで確認できます。
>echo %path%
もちろん「cd 上記5で確認したパス」としてからadbコマンドを使えばいいじゃん、という考え方もあるのですが、とりあえず今回は%path%を一時的に変更して作業を進めましょう。おのずとわかってきます。
8)adbコマンドが実行できるか、「adb version」コマンドを実行してみましょう。
>adb version Android Debug Bridge version 1.0.31
ここまででadbコマンドが利用できるようになりました。
もし今後も頻繁にadbコマンドを利用することがある方は、Windowsのシステム設定を変更して「%path%」の値を恒久的に変更されることをお勧めします。
以下おまけ。
ユーザー単位での環境変数を恒久的に変更する方法
一)Windows+Rで「ファイル名を指定して実行」を表示し、「systemPropertiesAdvanced.exe」を入力し実行します
二)表示される[詳細設定]タブの右下「環境変数」をクリックします。
三)「username のユーザー環境変数」にて[新規]をクリックします。
四)以下の情報を入力し[OK]をおします。
変数名: path
変数値: %path%;上記5で確認したパス
例: %path%;C:\Users\trippyboy\Documents\adt-bundle-windows-x86-20140321\sdk\platform-tools
さて、これでadbコマンドが利用できるようになったと思います。
続いてnexus5に接続するためのドライバーをダウンロードしておきましょう。
コメント
おはようございます。
このサイトでスマートフォンの話題がでるたびに
俺もスマートフォンにかえようかな?思う俺です。
pleskはスマートフォンから、操作できるぽいけどためしたことありません。
さて、nginxでリバースプロキシーを試した結果です。
個人的な体感速度によります。
自分のwordpressをnginx&nginxでやったら
はええええこれすげえええええ!!と感動。
こりゃ絶対入れたほうがいい。
会社のwordpressをnginx&apacheで仮想サーバーにて試した結果
確かに早いけど、微妙・・・・。
どうしてもapache共存が必要な人とかコンマ何秒とかでもはやくしたいとか
アクセスが多くてapacheじゃ処理しきれない人にお勧め。
Nginx入門によりますとnginx&nginxの方が早いそうです。
以上がプロキシーキャッシュでした。
しかし、昨日しったのですが、fastcgiキャッシュなるものがnginxにはあります。
proxyキャッシュはconfファイルとかもっさりしてめんどくさいとか
キャッシュは便利だけど、キャッシュのクリアする方法(nginxをリビルド)が必要になってきます。
proxyキャッシュとfastcgiキャッシュ
速さが同じくらいらしいのでfastcgiキャッシュを使うのもいいかもしれません。
おはようございます。
昨晩からリバースプロキシの設定を追加してみました。
体感速度はあんまり変わらないです(´;ω;`)ウッ…
やまり外部サイトから持ってきているコンテンツが多いので、それらを表示するのに時間を要している様です。
面白くなってきたので、これからも少し高速化ができないか、手隙で試してみる予定です(^_^)/
おはようございます。
>やまり外部サイトから持ってきているコンテンツが多いので、それらを表示するのに時間を要している様
youtubeの動画なんかはりつけるとやはりおそいです。
Nginx Cache Controllerを使う場合php-fpm&nginxとnginx&apacheいずれにせよ。動かす権限を統一する必要がでてきます。
俺はnginx.confで
user apache apache;に変更
ローカルに仮想サーバーをつくって他のさーばーからabコマンドで検証しました。
http://www.superweibu.com/ab.txt
くりくりさん
こんにちは。
リバースプロキシ、やはり早くなるのですね。
私の設定が未熟だったのかなぁ。。nginxとphp-fpmとリバースプロキシでもっと早くなるか、また試してみます。
今のところはPagespeedモジュールが使えるようにコンパイルしたnginxで頑張ってます。
今晩は
私も色々調整中です。
何かの参考になるかなと思いサーバーの教科書みたいplesk11のリバースプロキシーを見てみました。
confファイルをみてみるとこれキャッシュ化する設定がまったくない。
バーチャルホストのserverブロックをみてみると
listenディレクティブとserver_nameディレクティブと
Location / { proxy_pass http://127.0.0.1:8080; }
後はipがかわらないようにproxy_set_headerディレクティブがあるくらいです。
この設定だと全部バックエンドのアパッチに丸投げです。
キャッシュ化しないとリバースプロキシーの意味がないと思うですが・・・。
今にして思えばapacheだけでうごかしましょうよなんてレンタルサーバーの連中があっさりいってたし
リバースプロキシーの意味がないと知っていたのかもしれません。
いつかplesk11のリバースプロキシーを動かそうと考えていましたが、これですっきりしました。
おはようございます
ちょっと考察してみました。
nginxで運用しているWebサーバーに対して、RevrseProxyとしてnginxを利用するのはメリットがあまりないのではないかという結論です。
というのも、ApacheをバックエンドとしてnginxをReverseProxyとした場合、Apacheを超える処理能力をもつnginxをReverseProxyとすることで、その効果は絶大になると思います。現行のApacheがListenするポートを80番ポート以外にして、nginxをReverseProxyとするだけで、Apacheのほかの設定は今までと同じままで運用できるからです。
あとは、 http://blog.serverworks.co.jp/tech/2012/09/21/nginx-03/ にあるようなキャッシュ設定をnginixで行えばいいと思います。
もし、client->nginx(ReverseProxy)->nginx(backend)という運用をするのであれば、たとえばbackendが複数ある場合などを想定するものと思いました。
ReverseProxyを設置してキャッシュできるものに関しては、ReverseProxy無しでもfastcgiモジュールのキャッシュ機能を用いてキャッシュできるからです。
ということで、私の環境は既にfastcgiモジュールでのキャッシュを利かせているので、ここでわざわざReverseProxyを立てなくてもいいのかなぁという結論に至りました。
追加で、「WP Super Cache」というWordPressのプラグインを用いてみようと思っています。
Nginxを使ったもう一歩進んだWordPressチューニング
おはようございます。
>nginxを利用するのはメリットがあまりないのではないかという結論
>私の環境は既にfastcgiモジュールでのキャッシュを利かせているので
fastcgiキャッシュは検証してませんが、リバースプロキシーと同じくらいというサイトをみました。
しかし、もうそっちいってるんですか・・・。
俺の計画では製作側にnginxのリバースプロキシーのキャッシュすげえええ→nginxならもっと色々はやくできるよ?
と会社にnginxを徐々に浸透させる計画でした。
>Nginxを使ったもう一歩進んだWordPressチューニング
これくらいが最終目標かなとおもってだったんですけど(笑)
ただ、supercacheは試しにやってみたら、
wp-config.phpはかきかえるは書き込みはできなくなるとかえらいめにあったので保留中なんです。
おはようございます。
最終的に以下になりました。
nginx(80) with pagespeed module and proxyCache
↓
nginx(socket) with fastcgi
pagespeedモジュールを利用しない場合は、爆速なのですが、コンテンツのミニマイズをしたりするのがプラグインよりも動作が軽快と感じ、この構成にしました。
ローカルからのアクセスだと、この構成で1秒に40リクエストぐらい処理できるようです。
[trippyboy@vps1 ~]$ ab -n 100 -c 50 https://blog.trippyboy.com/
This is ApacheBench, Version 2.3
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking blog.trippyboy.com (be patient)…..done
Server Software: nginx
Server Hostname: blog.trippyboy.com
Server Port: 80
Document Path: /
Document Length: 61759 bytes
Concurrency Level: 50
Time taken for tests: 2.445 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 6197700 bytes
HTML transferred: 6175900 bytes
Requests per second: 40.90 [#/sec] (mean)
Time per request: 1222.385 [ms] (mean)
Time per request: 24.448 [ms] (mean, across all concurrent requests)
Transfer rate: 2475.67 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 13 13.5 6 29
Processing: 69 923 391.2 1154 1264
Waiting: 61 921 391.9 1153 1263
Total: 92 936 382.0 1157 1289
Percentage of the requests served within a certain time (ms)
50% 1157
66% 1220
75% 1233
80% 1236
90% 1254
95% 1260
98% 1270
99% 1289
100% 1289 (longest request)
WebPageTestにてCDN以外Aになったので、満足してます(^^)
http://www.webpagetest.org/result/140612_AG_SW/
こんにちは
ごめんなさい。俺その話まで全然すすめません><trippyboyさんいいな。色々nginxで先に進んでいていいな・・・。
リバースプロキシーの話を会社で話をしましたが、いまいちの反応です。ただ、反対とかいう意見ではないので、会社にnagiosの監視サーバーがあるしこれをVPSにしてnginxを広めるつもりです。apacheのシェア低下も理由にかなり脅すつもりです。