脳とコンピュータがつながる世界はそう遠くないかも
どうもKoheiです
暑くなったり寒すぎたり体調管理に気をつけなきゃいけない日が続きますね。
自分は案の定風邪気味です。
さてまずは、ネット見つけた面白そうな記事を紹介します。
記事によると、特殊なデバイスを使って脳から別の脳へと直接的に思考を伝え、3人が意思伝達を取ることができたそうです。
なんだかSFチックな世界の話ですが、このような脳とコンピュータをつなぐ研究は昔から行われています。
今日はこの脳つながるコンピュータについて書きたいと思います。
考えて動かすコンピュータ
ブレイン・マシン・インタフェース（BMI）って聞いたことあるでしょうか。
簡単に言うと脳とコンピュータを直接つなぐ仕組みのことを言います。考えただけて コンピュータを操作できる、攻殻機動隊で出てきそうなアレです。
脳活動を何らかの手段を使って計測し、その情報をもとにコンピュータをコントロールします。念じてロボットの腕を動かしたり、文字盤を見て思考するだけで文字入力ができたり、といったことを実現する技術と言われています。
脳活動をどうやって計測するのか
脳活動を図るというと、頭に電極を埋め込んだり・・・と、ちょっとオソロシイイメージを浮かべる人もいるかもしれません。
確かに過去には電極を埋め込んで計測するケースもありました。
（侵襲式と言われます。）高精度で脳活動を計測できるメリットもありますが、脳に損傷を与えてしまうことや、電極の経年劣化などのリスクがあり、ハードルが高いのが現状です。
そこで昨今盛んに研究されているのが非侵襲的な計測方法です。例えば、上記の記事でも使われているような脳波です。頭に電極を張り付けるだけだったり、最近だと被るだけのお手軽な脳波計も出ています。
なんとamazonにも売ってます。
●Emotiv社製 Emotiv Insight 脳波センシング高機能脳波計,各種Emotivアプリを入れたDVD付属(Classic White) ※日本語取扱説明書付
- 出版社/メーカー: Emotiv社
- メディア:
- この商品を含むブログを見る
主にこうした非侵襲式で使われる脳活動は
- 脳波
- 脳血流量
- fMRI
体に重度の障害を持つ患者の希望に
こうしたBMI技術ですが、期待されている分野に医療があります。特に、体の筋肉が衰え動かせなくなる難病であるALSで動かせない人（筋萎縮性側索硬化症）の生活支援として、期待されています。
こちらの記事でも紹介されていますね。style.nikkei.comALSの症状が進んでしまうと、脳活動は継続したまま、筋肉がすべて衰えてしまうので、周りの人の声は聞こえて理解ができるが、話すこともできない閉じ込め状態になってしまします。こうした患者の希望の光になるのがこうしたBMIになるというわけです。
こちらの記事でも紹介されていますね。style.nikkei.comALSの症状が進んでしまうと、脳活動は継続したまま、筋肉がすべて衰えてしまうので、周りの人の声は聞こえて理解ができるが、話すこともできない閉じ込め状態になってしまします。こうした患者の希望の光になるのがこうしたBMIになるというわけです。
実用化に向けた課題
さて、こうしたBMI技術ですが、どれくらい実用化に近いものなんでしょうか
最初に紹介した記事でも「3人で脳と脳で直接意思疎通できた」とありますが、やっているのはテトリスのブロックを回転させるか否か？の二択を送っているだけです。
1bitの情報だけということですね。
やはり、非侵襲式の脳活動は非常にノイズが多く正確な脳活動の把握が難しいのが大きな課題として挙げられています。
昨今のAI技術の進歩で、かなり精度よく特徴抽出を行うことができるようになってきましたが、それでも実用のためには、長時間のデータ計測が必要だったり。。。とハードルがあります。
とはいえ、将来的にも大きな注目を集めている技術の一つです。
5年後には1.7憶米ドルにもおよぶ市場になるとも予想されています。
BCI市場は2022年までに1.73億米ドルに | 医療機器の製造・開発 展示会・セミナー Medtec Japan |東京ビッグサイト
まあこれはちょっと盛り過ぎな気もしますが。。。Garnerのハイプサイクルでも「過度な期待時期」と言われていますし・・・
まとめ
さて、近未来の技術であるBrain machine interfaceについてまとめてみました。
まだまだ発展途上の技術ですが、昨今のAI研究のおかげもあり、着実に実用化に向けて進んでいる分野になっています。今後の動向にもますます注目ですね
ではでは
新入社員あるある7選！！(ディス多め)
どうも、ITコンサルタントのShoheiです。
10月1日、多くの企業で内定式が行われましたね。初々しいスーツ姿の青年たちを沢山見ました。
さて、今日はそんな彼らを見て思い出した昔の思い出を、新入社員あるあるという形で書いていきたいと思います。
①華金アピール
4月の最初の金曜日には以下のようなツイートが流れてきますね。
確かに学生時代、毎日休日みたいな過ごし方をしていた人も沢山いるので、気持ちは分かります。
ただ、華金は以下のようにあくまで"金曜日"を修飾した言葉なので、「華金した」というのは違和感ありますね。
花金・華金とは、漢字がどっちであっても「はなの金曜日」という意味です。週休二日制の導入で、翌日（土曜日）の出勤を気にせずに夜遅くまで楽しめるようになったことから、「はなきん」と使われるようになりました。
花金・華金という言葉が流行ったのは約30年前のバブル時代。景気が良く、世間全般が華やいだ雰囲気を持っている時代でした。「金曜日は遊べる華の日」として流行した言葉だったのです。*1
②抜けない学生用語と使っちゃう社会人用語
僕もしばらくそうでしたけど、学食など学生用語使っちゃうんですよね。
逆に納期とか社会人用語を無駄に使ってくる奴もいたり。
③残業時間をやたら比べたがる
以下のように、やたら残業時間で張り合おうとする人いますよね。
残業＝カッコいい と勘違いしてる人も少なからずいて滑稽ですね。
声を大にして残業してる人は、経験上大体効率悪いか、先輩について黙ってみてるだけか、残業時間増やそうと無駄に時間過ごしてるか、ですね。
④社会人になると●●だよ、という謎の呼びかけ活動
社会人代表のつもりなのかなんなのか、Twitter等で謎の呼びかけ活動を始めます。
んまぁ確かに時間は取りづらくなるけど、9日ぐらいの休暇はとれる企業普通に多いので、行動力と時間とお金のコントロール力があれば、海外旅行ぐらいいけます。
⑤定型文と化す自己紹介
以下のような自己紹介が量産されます。
個人的にはそんな個性のない自己紹介よりは「お手柔らかにお願いします(笑)」とか、「趣味は●●だったので、●●でお困りでしたらお声掛けください」ぐらいのユニークな文章は欲しいなぁと思います。
逆に自己紹介させる側も、「んじゃぁ、趣味と好きな食べ物も合わせて言っていこうか」ぐらいフランクにかつ個性を引き出す質問がないと、本当に相手のことを知れる自己紹介の場にはなりませんよねぇ。
⑥チームの成果を偉そうに語りがち
仕事内容を聞かれると、先輩がやってるであろう大きな仕事を答えたり、謎にカッコつけて組織のミッションだけ答えたりなど、自分ではまだ何もできてないのに偉そうに回答する人いますよね。
「で、君は何してるの？」「どんな困難乗り越えたの？」「あなただからできたことは何？」なんてと尋ねると大体その人は困ります。何故ならただついてみてるだけのケースも多いから。
この手の質問って、本当にその人が成し遂げた成果やプロセスが見えてくるんですよね。だから昇格試験や入社試験によく使われるんでしょうね。
それは置いておいて、この手の質問に以下のように答える人は、個人的には好感もてるし、自分の立場わかってるから成長するんだろうなぁと思います。
「いやー俺はまだ全然大したことできてないんだけどさ、チームとしては●●が目標なんだよね。俺も早くできるようになりたいけど…」的な前置きがあるとまた印象は違うなぁと思いますが。
⑦大したことないのに社畜アピール
飲み会中、おもむろにSlackとかを開きだして「トラブってんなー」とか言い出し出すやついますね。
まだ何もできない君はお呼びじゃないし、今見ても見なくてもどうせ何も変わらないんだから、目の前の飲み会に集中しなさい、と思いますわ。
あと、「土日もメールはみてるわぁ。まわんないもん」とサビ残アピールするやつもいますね。
必要に駆られてとか、意味あってやってるならいいですけど、ただ社畜アピールしたくてやってるだけなのは寒い話ですよねぇ。でも残念ながら新入社員あるあるで、毎年一定層はいるんだろうなぁと思います。
まとめ
今日は新入社員あるある７選を、ディス多めでお話ししました。
他にもこれあるくね？とかあればコメントやTwitter等でコメントください。
【社会人必見】エクセルを使う理由について
どうも、Keiです。
三連休初日ですね。大型台風の進路によって旅行の日程を変えた人も多いのではないでしょうか？
はい、僕もその１人です。
今回はエクセル、そしてエクセルの機能であるマクロについて取り上げてみます。
いやいやいや、エクセルなんて生まれたときから知っているよ。
今から学習するならPythonとかSwiftとか今後熱くなる言語覚えたいよ！っていう人も多いかと思います。
まあ、その通りなんですけどね。
というのは、エンジニアとか普段エクセルなんて使わないという人にとってはこの記事は魅力的ではないでしょう。
一方で、業務でエクセルやパワポを使って、上司やクライアントに説明を行ったり成果物を提出しているという人にとっては、マクロは業務を効率化してくれる非常に有用なツールとなります。
僕もエクセルのマクロなんて・・・って軽視していたタイプなので、今回エクセルの重要性を再認識できました。
なぜ、エクセルを使う？
お前は何を言っているんだ？ って感じですよね。
エクセルもパワポも昔からあるツールで、パワポを「shift+F5」でスライドショー化できない情弱そうな会社のおじさんでも知っています。
社会人であれば、エクセル・パワポは当たり前のように使うことでしょう。
しかし、１回ここで「なんで僕たちはMicrosoftのこのツールを使っているのだっけ？」というところを考え直してみましょう。
まずは利用シーン。利用する目的ですね。
- データの保存
- データの分析
- プレゼンテーション
データの保存は良いでしょう。
会社の経理データをエクセル形式でまとめて、ずっと保存しているケースは非常に多いかと思います。
次にデータの可視化は、経理データなどの「元データ」をクレンジング（削ったり、加工したり）して、グラフを作成することです。
このグラフから、元データの性質や傾向を分析することで何らかの示唆を出すケースもエクセルのメインの使い方でしょう。
最後にプレゼンテーションは、エクセルを見ながら相手に事実や示唆を説明することです。
次に利用する理由です。
- 洗練された便利な機能
- 世界中多くの人が使っている
- バグが限りなく少ない
自明な理由ばかりですが、個人的に重要だと思うのは「世界中多くの人が使っている」という点です。
成果物として、クライアントに提出するファイルの形式もエクセル、パワポを使っていれば問題ないですよね？
「え～、うち、LinuxのLibreofficeなんだよね～」とか聞いたことないですよね！？
このように、シェアがこれほど異常にあると、チームの誰かが退職しても引継ぎファイルがエクセルなら、計算式も書いてあるし、誰でも理解できます。
「この引継ぎ資料、Perlかよ、、おれわかんないんだけど、どうしよ？」なんて絶望に陥ることもありません。資料が属人化しないのですね。
もちろん、エクセルの書き方が汚くてお手上げっていうのはありえます。
読めるけど、意味わからんってパターンですね。
マクロについて
さて、マクロについてですが、マクロはプログラミングみたいなものなので、確かに上で上げた属人化の危険性があります。
そのため、クライアントに提出するような成果物にマクロを書いてドヤ顔するようなことはやめましょう。迷惑になります。
なので、マクロは自分の業務効率化に使うべきだと思います。
目的が業務効率化なら、エクセルじゃなくても良いとも思いますが、上司に自分が作った業務効率化ツールを共有する際に「Pythonで作りました～」より「エクセルのマクロです」の方が新設ですよね。
持論となりますが、エンジニア以外ならエクセルのマクロマスターになった方がプログラミングマスターとなるより良いのではないかと思います。
マクロは、プログラミングと違って「マクロの記録」があり、自分がマウスでエクセルにした操作を記録し、全部マクロを１から書かずとも、プログラミングが作れる機能があります。
これを使うと、プログラミング初心者でも速くマクロを使いこなせるかと思います。
さて、いかがでしたでしょうか？
エクセルなんて時代遅れツールなんて、と思っている方が重要性について今１度考え見直して頂けたら幸いです。
まあ、共有が楽で属人性でないツールが現れれば、エクセルじゃなくてもいいんですけどね。
それではまた。
データ分析で困ったあるある7選
どうもKoheiです。
最近の週末雨が多すぎやしないでしょうか
さて、今日は最近仕事で感じるデータ分析で困ったあるある7選をまとめて共有したいと思います。
データ分析を仕事にしている方、またはデータ分析を誰かにお願いする立場の方も、データと日ごろ関係のない方も、こんなことが実際には起きてるよ！というのを共有したいと思います。
では分析の準備編、分析実施編、分析結果共有編の3パートでそれぞれ書きたいと思います。
分析準備編
1. そもそもデータが集まらない。
いきなりそもそも論です。
実際に業務を進めて行くと、データ分析を行うターゲットや効果がイメージできるのにデータが集まらないパターンが多々あります。
データが集まらない理由というのはいくつかあって
・システムの制約でデータを出力できない、貯められない。
・セキュリティの問題上、持ち出すことができない。
・組織上の管理、整理の問題
などなどがあげられます。こうした理由を打破するためには、「データが集まったとき想定される効果をいかに具体化できるか」がカギです。
2. 分析業務の費用対効果が明確化しにくい。
とはいえ、分析の結果どれくらいの効果が見込めるかを見積もるのは非常に難しいです。なぜなら、データの中身がわからない段階で、そのデータからどんなことがわかるのかはやってみたいとわからない面が大きいからです。
これはお客様への営業を行う際には大きな壁になります。
効果出るかわかんないけど、なんか良さそうな気がするから、うちと契約して分析させてくれ・・・と言ってもなかなかお金を出してくれる会社はありません。
この課題に対しては、これまでの分析知見や他社の事例などをひっぱってきて、定性的な効果を積み上げるところから始めていくことになります。
3. データサイエンティストにデータを上げれば結果が返ってくると思われてしまう。
さあ、いざ解析スタート！となったときにあるのですが、依頼元からの「データ丸投げであとはよろしく」です。
これではとてもデータからよい効果を出すことはできません。
データサイエンティストは、あくまでデータ解析のスペシャリストであって、業務のスペシャリストでないことがほとんどだからです。
データ解析をお願いする立場の人が、いかにデータの裏側に潜む業務の知識（ドメインの知識と言ったりします）やそのデータをどう使いたいかを具体化して分析者に伝えることができるかがカギになります。
なんかよさそうなデータあるからよろしくーぽいーをしている時点で、その分析案件が成功するかはかなり怪しいです。
分析編
4. データが汚すぎて、中身の把握だけで長時間かかる。
これは3.の丸投げパターンのときにありがちです。
依頼元がデータの解析に興味がないorデータを知らないなどの要因で、ゴミデータや間違ったデータが混在したり、解析しにくい形式のままだったりします。
実体験であったひどいケース
- 数値の書いてあるWordファイルだけを渡される。
- 分析してみたら欠損だらけのデータ。
- 実はダミーデータが混ざってて、分析やり直し
ぜひ分析を依頼する人はちょっと解析する人のことを考えてあげてください。
分析者とのコミュニケーションをとりながら、データの提供元もどんなデータを用意すればよいかを合わせて考える必要があります。
5. データが巨大すぎて解析できない or 解析結果が出るのに数日かかる
まさにbigdata時代ならではの悩みです。
解析対象のデータが数百GB、ときに数TBにもおよび、コンピュータリソースはあっという間に足りなくなっていきます。
これは「データを分析するプラットフォームを拡張する」「分散処理のアーキテクチャを利用する」といった抜本的な方法を必要とされるケースもありますが、「分析対象を小さくしてスモールスタートで進める」「データの形式に合わせたソフトウェアを使って解析する」など工夫しながら進めていくことが大事です。
分析結果報告編
6. いろんな尺度で分析したが、結果のレポートを整理しきれず、伝わらない。
せっかくデータも集まって、多種多様な統計処理をこなしていくと、様々な側面からの解析結果が集まります。苦労して集めたデータをキレイに前処理して…と進めていくと、ちょっと分析者としても頑張りたくなるからです。
様々な尺度で解析をしていくのは楽しいですが、結果を待つ人からすれば、まずは期待している回答を出してほしいというのが本音です。
そもそもの分析目的はなんだったのか、というのを念頭に置きつつ解析結果を報告し、プラスアルファでこんな知見も見られました・・・という形で伝えることが大切です。
7. 精度の高い結果が出ても、業務上は役に立たないと言われてしまう。
さあ、分析も波に乗って、機械学習も組み合わせて、いい感じの判別モデルができました！さあこれをぜひ業務で使ってください！と、意気揚々にしていると、「なんかすごそうだね、へー」っと一度は感心されつつ、結局使われない・・・なんてことがあります。
「今まで人間が判断した内容を機械が判定するのは納得がいかない」「機械学習のロジックが説明できない/理解できないから使えない」といった感情的要因が時に出てきます。
こうした点は、データサイエンティストと実業務の担当者との溝が原因です。
お互いにコミュニケーションを取りながら、「実際にデータからこんなことが見える」「業務を進めるためにはこんな点が重要なんだ」といったお互いの観点をうまく交換しながら進めていくことが不可欠です。
まとめ
さて、ここまでデータ分析で困ったあるあるを紹介してきました。
もし、同じような悩みを抱えていた方、その悩みに対してこんな解決策をとったよ！という方がいればコメントいただけると嬉しいです。
ではでは
httpとは 〜みんな毎日http通信してるんだから基本ぐらい抑えておこう！
どうも、ITコンサルタントのShoheiです。
今日はhttpについて説明していきます。
※Verion 1.1をベースに説明していきます
そもそもhttpってなんだろう
よくホームページ等をみたりするとき、URLと言ってhttpやhttpsから始まる文字列が表示されますよね。(例: https://go-mount.hatenablog.com)
あれは、これはhttp(https)というプロトコルでWebサーバとやりとりしますぜと宣言をするための文字列です。(Webサーバの説明はWebサーバって何？？脱IT初心者！ - IT社員3人組によるリレーブログ を参照ください)
プロトコルは何かというと、通信をするための約束事のことです。
以下の図のように、通信をする際は必ず相手とどんなプロトコルでやりとりするかが明確になっている必要があります。
httpプロトコルの超概要
では、httpプロトコル(約束事)では何が約束されているのでしょう。
要点だけ、概要でお伝えします。
クライアントサーバモデルのやりとりを前提としている
横文字出てきましたがまだ難しくないので離脱しないでね。要はこういうこと。
例えばブラウザ(IEとかFirefoxとかSafariとかChromeのことね）開いて、何もしていないのに勝手にITリレーブログの記事が出たり、Youtubeで動画流れ始めたりしないですよね。
Webページを表示するためには、URLをいれるとか、検索をするとか、なんらかのアクションが必要。
このアクションは、リクエストと呼ばれていて、リクエストをしたPCはクライアントと呼ばれます。
リクエストは誰に飛ぶかというと、欲しい内容を持っているWebサーバに飛びます。
httpではこの、「これちょうだい！(リクエスト)」「了解、送るね！(レスポンス)」が必ずセットになるプロトコルです。
何をもらうの
リクエストで何をもらうかというと、Webページのコンテンツ(htmlファイルなど)です。
それを受け取ったクライアントはは、データを組み立ててブラウザに表示させます。
こうしてみなさんが今見ているページの表示が実現されます。
やりとりはどんな形で行われるの
こんな感じです。
通訳書いているので事細かには説明しないですが、二点だけ解説。
レスポンスコードとは
逆にリクエストに答える側は、リクエストがどう処理されたか（レスポンスコード）をセットで返すことになっています。
今回は 200 OK、正常に受理されたぜ、という内容を返していますが、他にも以下のようなレスポンスコードがあります。一例を紹介。
- 200 OK: 正常にリクエストを処理したよ
- 301 Moved Permanently: そのURL古くて、今は別のところにあるんだわ
- 400 Bad Request: いやリクエスト意味不明。間違ってない？
- 401 Unauthorized: 君は認められてないよ (認証が必要だよと伝えるケースと、認証が間違ってるよと伝えるケースあり）
- 404 Not Found: そんなコンテンツないぜ？ (男が悲しむ"This video has been deleted"的な)
- 500 Internal Server Error: ごめん、Webサーバ側の問題でエラーだわ
失敗をしているのは400代と500代。400代はクライアント側の問題だよ、500代はサーバ側の問題だよ、という内容になっています。
http(Version 1.1)の特徴
httpの特徴はシンプルさですかね。「くれ」「やるよ」が基本となり、余計なことはやらない。
ただ、逆に余計なことをやらなすぎて、今の時代に必要な機能がないことで、必要な機能をhttpプロトコル外で実装する必要があります。例をあげます。
セキュリティ的に弱い
例として、データが平文(暗号化されていない状態)で飛んでしまうという点があります。
この状態では、もしもやりとり中のデータを横取りされたら、クレカ情報でもなんでも盗み取られてしまいます
➡︎そのため重要なデータを扱うようなページはhttpではなく httpsというプロトコルを使われることが多いです
http/2の登場
上記の課題に対処するために、2015年にhttpのversion2が出ています。
version2についての詳細はここではふれませんが、ブラウザとサーバ側で対応しないと2は使えません。主要ブラウザは対応していますが、サーバ側はまだまだ普及仕切っていない状況です。
試しにこのブログのプロトコルも調べて見ましたが、まだVersion1.1が使われていますね。逆に約20年前のプロトコルが今でも使われているのは、すごいことだとも思います。
書籍紹介
この知識は、以下の本から得ました。グーグルに勤めている知り合いにおすすめされて読んだんですが、確かにおすすめですよ。読みやすいし、会社名など具体的な例をだしてくれるし、Web関連の攻撃の解説も全て具体的で非常にわかりやすい。
少し古い本なのでversion 2の解説はないですが、httpの基礎を学ぶにはかなりおすすめです。
- 作者: 上野宣
- 出版社/メーカー: 翔泳社
- 発売日: 2013/05/25
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (8件) を見る
まとめ
httpの基礎について説明しました。
【Python+Google Analytics】はてブのアクセス解析をやってみた①
どうも、Keiです。
台風が2連続で来ていますね。今年の日本の天気からは、紅葉に見惚れる隙も与えず冬に直行させるという鬼畜っぷりが伺えます。
さて、今回ですが当ブログ記事も多くなってきたので分析をしたいと思います。
一応、Google analyticsに登録しているのでGoogleのダッシュボードを使っても十分過ぎるほど分析はできるのですが、今回はGoogle analyticsが出しているAPIを使用して分析を行っていきたいと思います。
特に、今回はAPIのクライアントのプログラムとしてpython3.5を使います。
まず、APIを使うためにはGoogleのIAMの設定を行う必要があります。
IAMは誰（ID）がどのリソース（API等）をどんな権限でアクセスできるかについて設定するものです。
このように、下のサービスアカウントにアクセスするとIAMの設定ができます。
まず、サービスアカウントを作成します。
ここで、秘密鍵を保存する画面が出てくるので必ずなくさないよう保存しましょう。
さて、ここからはようやくpythonが出てきます。
クライアント側の設定はこちらもGoogleに丁寧にソースコードが貼られていたので、これを利用します。
from apiclient.discovery import build from oauth2client.service_account import ServiceAccountCredentials def get_service(api_name, api_version, scopes, key_file_location): """Get a service that communicates to a Google API. Args: api_name: The name of the api to connect to. api_version: The api version to connect to. scopes: A list auth scopes to authorize for the application. key_file_location: The path to a valid service account JSON key file. Returns: A service that is connected to the specified API. """ credentials = ServiceAccountCredentials.from_json_keyfile_name( key_file_location, scopes=scopes) # Build the service object. service = build(api_name, api_version, credentials=credentials) return service def get_first_profile_id(service): # Use the Analytics service object to get the first profile id. # Get a list of all Google Analytics accounts for this user accounts = service.management().accounts().list().execute() if accounts.get('items'): # Get the first Google Analytics account. account = accounts.get('items')[0].get('id') # Get a list of all the properties for the first account. properties = service.management().webproperties().list( accountId=account).execute() if properties.get('items'): # Get the first property id. property = properties.get('items')[0].get('id') # Get a list of all views (profiles) for the first property. profiles = service.management().profiles().list( accountId=account, webPropertyId=property).execute() if profiles.get('items'): # return the first view (profile) id. return profiles.get('items')[0].get('id') return None def get_results(service, profile_id): # Use the Analytics Service Object to query the Core Reporting API # for the number of sessions within the past seven days. return service.data().ga().get( ids='ga:' + profile_id, start_date='7daysAgo', end_date='today', metrics='ga:sessions').execute() def print_results(results): # Print data nicely for the user. if results: print('View (Profile):', results.get('profileInfo').get('profileName')) print('Total Sessions:', results.get('rows')[0][0]) else: print('No results found') def main(): # Define the auth scopes to request. scope = 'https://www.googleapis.com/auth/analytics.readonly' key_file_location = 'secret_key.json' # Authenticate and construct service. service = get_service( api_name='analytics', api_version='v3', scopes=[scope], key_file_location=key_file_location) profile_id = get_first_profile_id(service) print_results(get_results(service, profile_id)) if __name__ == '__main__': main()
いろいろ書いてありますが、基本コピペでOKです。
しかし、print分だけ、python2.7用で書いてあるので、python3.5以上の方は注意が必要です。
大事な部分は下の秘密鍵のファイルのパスを入力する部分で、ここを書き換えてあげましょう。
key_file_location = 'secret_key.json'
秘密鍵ファイルには秘密鍵の他にもJSON形式で自分のアカウントに関する情報がのっているようです。
ぼくも少しつまってしまったのですが、これだけだと下記の2つのエラーが出てしまいます。
・"Access Not Configured. Google Analytics API has not been used in project [プロジェクト名] before or it is disabled.
・"User does not have any Google Analytics account."
これらには、それぞれ下記の対処が必要となります。
・"Access Not Configured. Google Analytics API has not been used in project [プロジェクト名] before or it is disabled.
Google APIsのライブラリから"Analytics API"と"Google Analytics Reporting API"を有効にします。ここで、"Analytics API"では認証情報の設定も行います。
つまり、APIが有効になってなかったんですね笑（これだからAPI素人は・・・）
・"User does not have any Google Analytics account."
Google analytics側での設定も必要みたいです。今度はGoogle APIsから離れて、Google analyticsのダッシュボードに行き、「設定」の「ユーザ管理者」を選択します。
次に、Google analyticsにアクセス可能なユーザの設定欄にGoogle APIsで作成したサービスアカウントのメールアドレスを追加します。
ようやくバグとりが終わりました・・
さて、こちらのpythonを実行してみると、次のような結果が返ってきます。
どうやらget resultsで定義されているように、今日まで7日間のセッション数の合計値が表示されるようになっているようです。
う～ん、まだまだ少ないので増やしていきたいですね。
実際にデータを整形していくのは次回としたいのですが、
簡単にmetricsとdimentionsについて説明させて下さい。
先の例では下のようにmetricsやその他のパラメータを指定することで、Google APIにこんなデータが欲しいよというクエリ（リクエスト）を投げていました。
return service.data().ga().get(
ids='ga:' + profile_id,
start_date='7daysAgo',
end_date='today',
metrics='ga:sessions').execute()
ここでは、もっとクエリに条件を追加することで複雑なレスポンスを受けることができますが、必須なのが上記のパラメータなのです。
- ids：サービスアカウントの識別子
- start_date：欲しいデータの集計開始日（日付指定も可）
- end_date：欲しいデータの集計終了日（日付指定も可）
- metrics：欲しいデータの種類（ここではセッション数）
metricsに例えば、ga:pageviewsを入力すれば、今回で言えばpageviewの合計値が表示されます。
次にオプションとして重要なパラメータとしてdimentionsが挙げられます。
これは、metricsで欲しいデータをdimentionsで指定したパラメータでカテゴライズすることができます。
例えば、下のクエリを見てみましょう。
return service.data().ga().get(
ids='ga:' + profile_id,
start_date='7daysAgo',
end_date='today',
dimensions='ga:day',
metrics='ga:sessions').execute()
dimentionsではga:dayを指定していますが、これによって7日のセッション数を一日当たりのセッション数ずつに分けてレスポンスを返してくれます。
dimentionsには1つだけでなく、最大8つまでパラメータを表示することができ、metricとの組み合わせで複雑なデータを得ることができます。
最後に、このdimentionsを使うためにGoogle Analytics上で下記を有効にしなければいけないみたいです。
TypeError: Got an unexpected keyword argument "dimentions"とでるだけで、
Webにもどこにも書いていなかったので、めちゃくちゃトラシューに時間がかかりました。
皆さんもお気をつけて・・・
それでは、実際にデータをゲットして加工して表示させるプログラムについてはまた次回！
コンテナ管理ツールのdocekr swarm/Kubernetesについて調べてみた
どうもkoheiです。
今年はいったいいくつの台風が来るんでしょうか・・・
さて、今日は前回に引き続きDockerについて
特にコンテナの管理ツールについて簡単に書きたいと思います。
正直まだまだ勉強中のところも多いので、ざっくり概要だけ紹介したいと思います。
コンテナってなに？って人は前回の記事をどうぞ
Dockerを実際に使ってみると・・・
Dockerを利用することで、Docker imageがあれば数秒で環境構築できたり、構成管理が容易になったり、docker imageとしてまとめて環境移行できたり・・・などすばらしい機能を提供してくれます。
さて、このdockerを使って、実際にWebサービスを提供する環境を作ってみよう！
となると、様々なニーズが出てきます。
- webサービスを提供するにしても、フロントエンドのWebサーバから、webサーバからの処理を返すアプリケーション、データベースなど、複数のアプリケーションが必要。それぞれアプリごとにコンテナを作って、複数コンテナを連携させたい。
- 安定してサービス提供を行うため、データベースはMaster/Slaveの冗長構成で、別々のサーバで、別々にコンテナを動かして連携させたい。
- 新しいコンテナを立ち上げるときは、リソースが比較的空いてるサーバに立ち上げてほしい
- コンテナがちゃんと起動しているか確認して、停止していたら再起動してほしい
実際にコンテナを使ったサービスを使おうとなると考えることが多い・・・。
と悩ましいところですが、こうした課題を解決すべく、いろんな機能やサービスが提供されています。
複数コンテナの連携
1.の複数コンテナの連携に対しては、docker-composeが有効です。
docker-compose.ymlというファイルにコンテナの組み合わせの定義や、起動順、コンテナ間の接続情報等を記載しておけば、docker-composeコマンド一つで簡単に複数コンテナの起動、連携ができます。
複数サーバ間でのコンテナの管理
さて、残り2. 3. 4.の課題を解決するための方法としては、Docker Swarm / kubernetesというツールが有名です。
Docker Swarm
docker社が提供する、コンテナ用のクラスタ管理ツールです。
たくさんのクジラがたくさんのコンテナを一緒に持ってますね。
docker swarmはコンテナの利用状況をチェックするmangerとコンテナを実行するagents側とで分かれています。
swarm mangerに向けて、コンテナの新規実行を依頼すると、agentsの稼働状況を確認して、任意のサーバでコンテナを実行してくれる仕組みになっています。
こうして、複数サーバ上でいい感じにコンテナ実行もできてハッピーな感じですが、実はdocker swarmは現在、主流のコンテナ管理ツールから外れつつあります。
コンテナの管理ツールとしては後述するkubernetesが現在主流になっています。
kubernetes
docker社が作っていたdocker swarmを差し置いて、コンテナ管理ツールの代表格となっているのがgoogleが開発したkubernetesです。（読み方はクバネティス、クーベネティス、クーベルネイテスなど。k8sと書くことも）
なぜ、docker社ネイティブのdocker swarmより主流になったのかというと、シンプルにより高機能だったから、と言われています。
結果的に2017年にはdocker社はkubernetesをサポートすることを発表しました。
kubernatesの機能としては、これまで話してきたdocker-composeやdocker swarmの機能も全部合わせて、さらにコンテナ間のネットワークルーティング管理等も可能にしています。
細かい話はしませんが、ざっと構成要素は下記のようになっています。
docker swarmの時と同じように、管理機能を持つmaster nodeと実際にコンテナを実行させるnodeに分かれています。docker swarmとさらに違う点としては、複数コンテナを集めてPodという単位でkubernetes上ではコンテナを管理します。
高機能だけあって、構成要素も多く複雑になりつつありますが、
それだけ様々な管理機能を提供してくれます。
webUIもついてます。（kubernetes公式サイトより）
とはいえ、自分たちでk8s環境作って運用するのは難しそう・・・というあなた
kubernatesをベースとしたクラウド上のコンテナ管理サービスというのも複数登場しています。上記のmaster nodeの部分がほぼ意識しなくてもよい形になるため、運用コストはかなり楽になります。
Google, Azure, AWSの各社それぞれ出しているのでざっと紹介します
Google KUBERNETES ENGINE (GKE)
Azure Kubernetes Service (AKS)
Amazon Elastic Container Service for Kubernetes (EKS)
まとめ
ここまでコンテナ管理ツールについて、書いてきました。
これらの情報についてはこちらの本を参考にしました。
手順も含めて丁寧に情報がまとまっていて、非常に参考になりました。
これらのコンテナ管理ツールですが、まだまだ発展途上の分野です。
高機能で複雑化しつつあるkubernetesから別のものが出てくるのでは？といった話も出ており、今後の動向が注目されています。
ではでは
