2017年09月07日

YouTube data API v3 のAPIキー取得の備忘録

YouTube API は、YouTube が提供しているWebサービスを利用できるように公開されたAPIのこと。
YouTube Data API の概要

Webサイトなどで YouTube API を使用する場合、ライセンス表示が必要。
You do not need special approval to use YouTube APIs or to promote API functionality in your application. However, any YouTube logo used within an application must link back to YouTube content or to a YouTube component of that application.
引用:YouTube API Services - Branding Guidelines



Googleアカウントでログインした状態だとして話を進める。

Google Developers Console にアクセス。
利用規約の更新が表示されれば、[はい] を選択し、[同意する] をクリック。
google_api05.png

google_api01.png

[ライブラリ] から [YouTube Data API] をクリック。
google_api02.png

APIを有効にするにはプロジェクトが必要とあるので、
まずは [プロジェクトを作成] をクリック。
google_api03.png

[作成] をクリック。
google_api04.png

プロジェクト名をつけ、作成する。
google_api06.png


作成したプロジェクト名が上部に表示されているはず。
[認証情報] から [認証情報を作成] をクリック。
google_api07.png

[APIキー] を選択すれば、APIキーが発行される。
google_api08.png

google_api09.png


再度、[ライブラリ] から [YouTube Data API] をクリック。
上部にある、YouTube Data API v3 を [有効にする] をクリックする。
google_api10.png

これで、YouTube Data API v3 が有効になる。
google_api11.png

[認証情報] のAPIキーを使い、YouTube Data API v3 が使える。
google_api12.png


テストする。
APIを使い検索してみる。
https://www.googleapis.com/youtube/v3/search?part=snippet&q=ここに検索したい単語を入れる&key=ここにAPIキーを入れる

失敗だったら、以下のようにエラーが出力される。
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "keyInvalid",
"message": "Bad Request"
}
],
"code": 400,
"message": "Bad Request"
}
}


成功していれば、取得結果がJSON形式のデータで表示される。
posted by Zorinos at 20:00| Comment(0) | ツール | 更新情報をチェックする

2017年09月05日

Apache2 で Basic認証 を設定

apache2 で Basic認証を設定する方法には
confに設定する方法と、.htaccessファイルを使う方法の2つの方法がある。
Basic認証(ベーシックにんしょう、Basic Authentication)とは、HTTPで定義される認証方式の一つ。基本認証と呼ばれることも。
Basic認証では、ユーザ名とパスワードの組みをコロン ":" でつなぎ、Base64でエンコードして送信する。このため、盗聴や改竄が簡単であるという欠点を持つが、ほぼ全てのWebサーバおよびブラウザで対応しているため、広く使われている。引用:Wikipedia


環境:
  • Ubuntu 16.04
  • Apache 2.4.18




ユーザーとパスワードの設定


どちらの方法でも認証のために、ユーザーとパスワードの設定は必要。先に作成しておく。


ユーザー管理ファイルを作成


管理ファイルを新規作成する場合、

$ sudo htpasswd -c ファイル名 ユーザー名

実行すると、パスワードの入力を求められるので2回入力する。

$ sudo htpasswd -c /etc/apache2/.htpasswd user1
New password:
Re-type new password:
Adding password for user user1


既に管理ファイルが存在していて、2回目以降のユーザー作成では、オプション -C を付けない。
$ sudo htpasswd /etc/apache2/.htpasswd user2
New password:
Re-type new password:
Adding password for user user2


ユーザー管理ファイルの置き場所はどこでもいいが、セキュリティ上、公開されていないディレクトリ上に作成すること。


パスワードの変更


パスワードを変更したい場合も、同様のコマンドで更新する。
$ sudo htpasswd /etc/apache2/.htpasswd user1
New password:
Re-type new password:
Updating password for user user1






ユーザーの削除


オプション -D を付ける。
$ sudo htpasswd -D /etc/apache2/.htpasswd user1
Deleting password for user user1





.htaccessファイルを使った認証方法


認証をかけたいディレクトリに .htaccess ファイルを置き、以下の内容を記述する。

AuthType Basic
AuthName "Please Enter Your ID and pass"
AuthUserFile /etc/apache2/.htpasswd
require valid-user


AuthType

認証方式を指定。 Basic認証の場合 Basic とする。

AuthName

認証画面に表示されるメッセージ。

AuthUserFile

作成したユーザー管理ファイルを指定。

require

アクセスを許可するユーザーやグループを指定。 valid-user の場合、ユーザー管理ファイルに含まれるすべてのユーザーを対象とする。


システムが .htaccess ファイルを見つけた時、このファイルの中で定義された設定を、既にこのディレクトリに対して定義されていた設定に対して上書きする必要がある。
これは apacheのディレクティブ設定で行う。

"/etc/apache2/sites-available/" に置いたconfファイルで設定する。
<Directory パス> 
  ~ 省略 ~
  AllowOverride AuthConfig ← None を変更する
  ~ 省略 ~
</Directory>

  • None :上書きを禁止
  • AuthConfig :認証に関する変更を許可
  • All :すべての設定の変更を許可


設定後、apacheを再起動する。

.htaccess ファイルを置いたディレクトリにアクセスする。
apache_basic01.png
設定した通り認証を求められるので、登録したユーザーとパスワードを入力すればいい。






confファイルで設定する方法


"/etc/apache2/sites-available/" に置いたapacheのディレクティブ設定で行う。

記述する内容は、.htaccess ファイル内に記述したものとほぼ同じ。
<Directory 認証を設定するディレクトリパス>
  AuthType Basic
  AuthName "Please Enter Your ID and pass"
  AuthUserFile /etc/apache2/.htpasswd
  require valid-user
</Directory>


設定後、apacheを再起動すれば、認証を設定するディレクトリに認証がかけられている。




まとめ


apache では .htaccessファイルの使用を推奨していません。
apacheでは認証用のディレクティブを書く方法が推奨され、.htaccess ファイルはサーバの設定ファイルを変更できない場合に使用すべきとしている。

理由としては、apacheが各ディレクトリで.htaccessファイルを探し、設定を書き換えるためサーバに余計な負荷をかけるというパフォーマンス上の問題や、.htaccessファイルは一般ユーザーが設置、編集できるのでセキュリティ上の問題があるため。
これらのことを理解したうえで、Basic認証を使い分けながら使用していく。


Ubuntu サーバの設定 Webサーバー
posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年09月02日

Twitter APIを使うための備忘録

Twitter APIを利用するには、Twitterのユーザーアカウントが必要。
アカウントにログインした状態だとして話を進める。

アプリケーションを登録する手順


Twitter Developersにアクセスする


https://dev.twitter.com/
twitterapi01.jpg

ページ下部にある「Manage my Apps」をクリック。
twitterapi02.jpg

「Twitter Apps」という「アプリケーションの管理画面」に移動できる。
よく使うページになるので、ブックマークしておくとよい。
twitterapi03.jpg
既に登録しているアプリがある場合はリストで表示される。
新規の場合は上図のように、「You don't currently have any Twitter Apps.」と表示される。



新規にアプリケーションを登録する


[Create New App] をクリック
twitterapi04.jpg
アプリケーション情報を登録する。
twitterapi05.jpg

Name

アプリケーションの名称。

Description

アプリケーションの概要。

Description

アプリケーションのウェブサイトのURLアドレス。仮のアドレスでもいい。

Callback URL

ユーザーがOAuth認証作業をした後の、戻り先となるURLアドレス。認証が必要ないアプリケーションの場合は空でいい。後からでも設定できる。

Developer Agreement

APIの利用規約。「Yes, I have read and agree to the Twitter Developer Agreement.」にチェック。

[Create your Twitter application] をクリック。
twitterapi06.jpg
※電話番号を登録していないとエラーが起こる。
twitterapi07.jpg

アプリケーションが作成され、管理する画面へ遷移する。
twitterapi08.jpg


最初の管理画面に戻ると、
作成したアプリケーションが追加されている。
これをクリックすると、先ほどのアプリケーションの管理画面に遷移できる。
twitterapi09.jpg




APIキー


APIキーの確認


アプリケーションの管理画面から、
[Keys and Access Tokens]のタブをクリック。
twitterapi10.jpg

「Consumer Key (API Key)」と「Consumer Secret (API Secret)」をメモしておく。
アプリケーションに振られるIDとPASSのようなもの。
twitterapi11.jpg







APIキーの変更


もしAPIキーの情報が他人に知られてた、もしく知られた可能性がある場合は、
[Regenerate Consumer Key and Secret] から変更することができる。
twitterapi12.jpg




パーミッションの設定


アプリケーションの管理画面から、
[Permissions]のタブをクリック。
twitterapi13.jpg

3つの設定の中から1つを選択する。
Read onlyRead and WriteRead, Write and Access direct messages
ユーザーのツイートを見る
ホームタイムラインを見る
プロフィールを見る
プロフィールを更新する×
ツイートを投稿する×
フォローする×
ダイレクトメッセージを読む
・送信する
××

(参考:Application Permission Model

変更したら、
[Update Settings] をクリックして更新する。
twitterapi14.jpg

[Additional Permissions] では
ユーザのEmailアドレスのリクエストができるようになっている。
いろいろとめんどくさい気がするのであまりよく知ろうとしていない。
GET account/verify_credentials





Access Tokenを取得


アクセストークンは、アプリケーションでユーザーの代わりに操作するために、ユーザーのアカウント情報(IDとパスワード)を暗号化してまとめたもの。
アクセストークンを取得するためには、ユーザーによる認証作業が必要となるが、自分自身のアクセストークンであれば、そんな手間をかけず、アプリケーションの管理画面から直接発行することが可能。

アプリケーションの管理画面から
[Keys and Access Tokens]のタブをクリックして移動。
ページ下部にある [Create my access token] をクリック。
twitterapi15.jpg

「Your Access Token」の箇所に情報が追加され、
「Access Token」と「Access Token Secret」が取得できる。
twitterapi16.jpg

アクセストークンを取得した後でパーミッションを変更したら、
アクセストークンを作り直す。
[Regenerate My Access Token and Token Secret] をクリックし、再度、取得する。
ラベル:TOKEN OAuth twitter
posted by Zorinos at 20:00| Comment(0) | ツール | 更新情報をチェックする

2017年08月28日

実践git

Git-Logo-1788C.png

公式サイト:https://git-scm.com/



インストール









1人でgitを使う


準備





基本的な作業



この流れの繰り返し。


リリース作業








複数人でgitを使う


準備






基本的な作業


リモートリポジトリからクローンして、ローカルリポジトリを準備すれば、後は1人でgitを使う流れと同じ。



他のメンバーと作業内容を共有







リリース作業


基本は 1人でgitを使う場合のリリース作業と同じ。





ブランチモデル








困ったときのtips


変更したファイルがたくさんある。ステージするのがたいへん。

  • $ git add .
    "."(ピリオド)を指定するとそのディレクトリ以下の階層すべての変更ファイルがステージの対象となる。

作業ツリー上に、gitで管理してほしくないファイルが存在している。


さっきコミットしたのに、追加を忘れたファイルがあった。


コミットしたコミットメッセージがいまいちだった。書き換えたい。


間違ってステージしてしまった。

  • ステージされているすべてのファイルをもとに戻す場合
    $ git reset HEAD
  • 特定のファイルだけ戻す場合
    $ git reset HEAD <対象ファイルパス>

間違ってコミットした。取り消したい。

  • 1つ前のコミット状態に戻す。ただし、作業ツリー、ステージングエリア上の変更は戻さない。コミットだけ無しにする。
    $ git reset --soft HEAD^

リセット実行したけど、実行前の状態に戻したい。


異なる目的の対応を一気にやってしまった。複数のファイルの変更点がある。分けてコミットしたい。

  • $ git add -p
    "-p" オプションをつけると、ステージする処理をインタラクティブに進める。
    変更ファイルが順に示されるので、コマンド入力でステージする・しないを決定する。コマンドの種類はいくつかあるが、ややこしい操作は無しにして次の操作だけ行えばいい。
    [y]ステージする、[n]ステージしない、[q]操作を中止する。

作業ツリー上の内容が中途半端でまだコミットできないのに、同じ作業ツリー上で、急遽、別の作業を行わないといけなくなった。


細目にコミットしたが、履歴を追うのが大変。まとまりある単位でのコミットにしておけば良かった。マージする前に整理したい。

  • git rebase -i で "squash" を指定してコミットをまとめる。

ブランチを切り替えるの忘れて、コミットしてしまった。

  • まず正しいブランチに切り替える
    $ git checkout <正しいブランチ名>
    コミットIDを使い、間違ったコミットを指定してチェリーピックする。
    $ git cherry-pick &ly;commitID>
    間違ってブランチに戻り、不要なコミットをリセットする。
    $ git checkout <間違ったブランチ名> && git reset --hard HEAD~

違うブランチを削除してしまった。

  • ローカルリポジトリの場合
    reflogで過去の作業から、ブランチ削除の前の状態を確認する。
    復活させたいブランチ名と確認した番号を使い、以下のコマンドを実行する。
    $ git branch <復活させたいブランチ名> HEAD@{確認した番号}
  • リモートリポジトリの場合
    すぐに他のメンバーに確認。リモートリポジトリを触って影響を受けないように連絡と、既に影響を受けてしまった人がいないか確認。
    そのうえで復活操作可能と判断できれば復活させる。すぐの操作が難しいとなればメンバー間で今後について相談する。

    復活手順:
    もしローカルリポジトリにも削除してしまったブランチがなければ、上記手順で復活させる。そのブランチをリモートリポジトリにプッシュする。ただし普通にはプッシュできないので、強制的にプッシュし復活させる。
    $ git push -f <リモートリポジトリ> <復活させるブランチ名>

リモートブランチは他のメンバーに影響を与える可能性が高い
焦って git push -f をしてはダメ。
メンバーに確認して、大丈夫だと確認が取れてから操作すること。

プッシュしたコミットが間違っていたので取り消したい。

  • 基本的にコミットを無かったことにするのはあきらめる。
    リモートブランチは他のメンバーに影響を与える可能性が高いので、コミット履歴を改変しないこと。
    git revert でコミットした歴史は残しつつ、内容だけ差し戻す。
  • もし他メンバーの誰にも影響が出ないことがわかったなら、例外的処置でリモートリポジトリを書き換える。
    まずローカルリポジトリでコミットをリセットする。
    $ git reset --hard HEAD^
    リセットした内容を強制的にプッシュする。
    $ git push -f <リモートリポジトリ> <ブランチ名>

スタッシュした内容を消してしまった。

間違って git stash drop したときや、git stash pop のあとに、うっかり git reset して大事なスタッシュを消してしまった場合。
  • "drop" や "pop" のスタッシュ操作したときに、
    例えば "Dropped refs/stash@{0} (13ce25271878e0763aaaefab44c0b2c52743df51)" と、SHA-1 が示される。これを使って復活させる。
    $ git stash apply <SHA-1>
  • もし、SHA-1 がわからない場合は、
    $ git fsck
    とすると、"dangling commit"(中間ファイルのようなもの)が列挙される。このどれかが消えたスタッシュ。
    上記操作で適用して地道に探してみる。

サーバーの入れ替えがあり、サーバーのアドレスが変わってしまった。


ローカルで1人で作業していたがチーム編成になり、今までの内容をメンバーに展開することになった。






gitの基礎


gitをインストール
gitサーバーのセットアップ
git ブランチについて
git 変更を一時的に退避 stash
git ブランチを合流するマージ
git ブランチを付け替える
git コミット履歴を変更する
git 変更をリセットする
git リモートでの操作
git ファイルの追跡
git リリース準備
git 変更をpatchファイルにする
git コンフリクトに対処する
git 失敗したときの復元


posted by Zorinos at 20:00| Comment(0) | Linux | 更新情報をチェックする

2017年08月11日

100均のクーラーボックスで簡易クーラーを作ってみた

クーラーボックスに保冷剤を入れて、上部から暑い風が入り、下部から冷たい空気が出ていくというもの。

Youtubeで100均ダイソーのクーラーボックスで作るというのを見て、


これに使われているダイソー扇風機、使ってるわ、って思って、
cooler01.jpg
涼しくなるなら作ってみよう。

って思ったんだけど、貧乏性がでてきて
使っている扇風機を奪われるのはちょっとな。。。
そういえば使っていないPCファンがあるけど、これで代わりにならないだろうかと。

で、調べてみたらPCファンで簡易クーラーを作っている人も多いな。できるんじゃないか。







材料


100均ダイソーでクーラーボックスを購入。税抜¥150。
cooler04.jpg
100均で、保冷剤を立てて置くために、まな板たてと、
USB充電ケーブルを購入。
cooler06.jpg
送出口として、ホームセンターでL字型の塩ビパイプを購入。

PCファンのカバー用には、家にあった園芸用の鉢底ネットを使う。
保冷剤も家にあるものを使う。
これでカッターとホットボンドを使って工作する。
あと、テスターはあったほうがいい。


しかし、心配事はある。
  • PCファンを動かすには、USB電源を使おう。楽だから。
  • PCファンは12v電源だけど、USBからは5v電源しかとれない。
  • そもそも5v電源で、このPCファンは回るのだろうか。
  • 回ったとして、十分な風力は得られるのだろうか。



まぁ試してみてみよう。
PCファンはこれ。
cooler02.jpg

80mm角の静音タイプ。
小さくて、静かな。その分、風量も弱い。。。
不安。



製作


まずは、穴をあける場所の位置決め。
風を上から送り込んで、下から送出するのだろうけど、
風量が心配なので、中で溜めて冷たくなった空気が漏れ出すようなイメージでつくることにした。
cooler03.png
加工をクーラーボックスの蓋だけで済むせることで、
簡易クーラーとしてはいまいちだったとしてもボックスとしては再利用しやすいという算段。


念のため、扇風機で風を送りこむことができるようにサイズだけは確認。
cooler04.jpg
蓋の枠にぴったりとはまっているように見えるが、実際には無理矢理押し込んでいる。

では、PCファンを使って穴をあける位置を決める。
cooler05.jpg
80mmサイズでちょうどいい大きさだった。

これに送出口となる場所を塩ビパイプで位置決めする。
あとはカッターで切って穴をあけて納めてみる。
cooler07.jpg


鉢底ネットをファンのサイズにカットして、蓋をすれば完成。
cooler11.jpg


次に、USBケーブルの加工。
cooler08.jpg
MicroUSBコネクタ側をカットして、ケーブルを剥き出す。
テスターで配線を確認。

PCファン側のコネクタの配線は
cooler09.jpg

普通はハンダでつけるけど、
ここでも貧乏性がでて、あとからPCファンとして復帰できるように、
PCファン側は加工せずに、強引にコネクタ側に銅線を差し込みホットボンドで固めた。
cooler10.jpg
見た目はともかく、
簡易クーラーとして使わなくなれば、ホットボンドで固めたところを強引に剥がせば、PCファンとして復帰できる。

USBを挿して電源を入れてみると、PCファンが回った。
が、予想通りに微風。超微風。

とりあえず、保冷剤を納めて、冷気を期待してみる。
cooler12.jpg

冷気が漏れ出してくるという表現がぴったり。

cooler13.jpg


期待通りといえばそうだが、
やっぱりこんなものかと言う達成感を感じない気持ち。
とりあえず、机の脚元において過ごしてみる。
PCの排気の熱を取りこみ、冷気に変換してくれているのか、ちょっと冷えている気がする。

なんか役に立っているかも。


まとめ


さすがに一気に冷やしてくれるという訳にはいかないが、それなりに活躍はしてくれているみたい。
静音ファンが低い電圧で動いているので、回転音がほぼしない。静か。
5v→12vに変換してもっとパワーアップさせて動かそうかと思ったけど、いまのままでもいいかな。
たまにファンが回らないときがあるが、そのときは指でファンを回すと動き出す。初動の力が足りないみたい。いいよ、これぐらいは手で動かすよ。



ラベル:PCパーツ DIY 自作
posted by Zorinos at 20:00| Comment(0) | DIY | 更新情報をチェックする