ただふれたものについて書くブログ

あんまり正しくない話を適当に書くブログ

いつの間にかre:dashの設定が簡単になってた(Dockerを使えば)

v0.8.2-rc の頃に一回入れたことがあったのだけど 当時は中途半端だったDockerサポートがきちんと整備されていて使えるようになっていた。

http://docs.redash.io/en/latest/setup.html#docker-compose

要は、postgres イメージと Dockerイメージがあれば動きますよって話。

https://github.com/getredash/redash/blob/master/Dockerfile にあるので、 まずは自分の手元でDockerイメージを作成する。

$ git clone git@github.com:getredash/redash.git
$ cd redash
$ docker build -t redash .

docker-compose.yml もサンプルもredashのリポジトリに入っているので、それを使えばひとまずお試しができる https://github.com/getredash/redash/blob/master/docker-compose-example.ym

$ mv docker-compose-example.yml docker-compose.yml

docker-compose-example.yml の中身はこれ。

redash:
  image: redash/redash:latest
  ports:
    - "5000:5000"
  links:
    - redis
    - postgres
  environment:
    REDASH_STATIC_ASSETS_PATH: "../rd_ui/dist/"
    REDASH_LOG_LEVEL: "INFO"
    REDASH_REDIS_URL: "redis://redis:6379/0"
    REDASH_DATABASE_URL: "postgresql://postgres@postgres/postgres"
    REDASH_COOKIE_SECRET: veryverysecret
redis:
  image: redis:2.8
postgres:
  image: postgres:9.3
  volumes:
    - /opt/postgres-data:/var/lib/postgresql/data
redash-nginx:
  image: redash/nginx:latest
  ports:
    - "80:80"
  links:
    - redash

ただし、アカウントの登録などの初期化処理が setup/docker/create_database.sh にまとめられている*1ので そちら経由でdocker-compose upを行う。

$ setup/docker/create_database.sh

初期化が終わったあといくつかのコンテナが抜けているのであらためて docker-compose up を実行。 2回目以降は普通に docker-compose up が使える。

f:id:taizo_onexone:20160702120722p:plain

dockerの動いている環境にポート80でアクセスすれば、Re:dashが試せる。 (アカウントの初期値は admin/admin。create_database.sh に書いてある )

環境変数について

環境変数はドキュメントの記載があまりないので、コードを直接見るほうが早い。 自分がさわったやつ。

変数名 説明
REDASH_STATIC_ASSETS_PATH assetsのpath
REDASH_LOG_LEVEL ログレベル
REDASH_REDIS_URL redis の向き先
REDASH_DATABASE_URL postgres の向き先
REDASH_COOKIE_SECRET cookieのsecret
REDASH_GOOGLE_CLIENT_ID google OAuth を使うときのclient id
REDASH_GOOGLE_CLIENT_SECRET google OAuth を使うときのclient secret
REDASH_GOOGLE_APPS_DOMAIN google OAuthでログインを特定のドメインのみにしたい時に使う
REDASH_ALLOW_SCRIPTS_IN_USER_INPUT クエリーの説明部分でフォームを設定したい場合に入れる

自分らが実際に利用する環境を用意する場合は、nginxとredash だけ docker化して、 redisとpostgres の向き先だけ別のものにしている。 後はGoogle OAuth でログインすると権限管理が楽なのでREDASH_GOOGLE_* を設定している。 REDASH_ALLOW_SCRIPTS_IN_USER_INPUT は便利そうなのでいれてる。

注意

上はgithubから直接落としてきたけれど、Docker Hubにあるタグがついているイメージを使ったほうが良いと思う。

https://hub.docker.com/r/redash/redash/tags/

参考

*1:https://github.com/getredash/redash/blob/master/setup/docker/create_database.sh

IT人材白書2016 ざっくり読んだ

開発

www.ipa.go.jp

育成のところがちょっと気になった。

  • EUでeリーダーシップというスキルが提唱されている
    • ビジネス、デジタル、組織的なリーダーシップを育成する
  • 日本ではIoT分野の立ち上げに技術力とビジネスアイデア構想力の必要性が高まっている
    • R&D部門と営業がセットになった組織体制を取ったりしてるんだとか。

f:id:taizo_onexone:20160629235719p:plain http://eskills-lead.eu/fileadmin/lead/reports/lead_final_report.pdf

上がeリーダーシップスキルトライアングル。 eリーダーに必要な能力要件がまとまっている。

日本ではIT融合人材ってやつみたい。 www.ipa.go.jp

いろいろあるんだなぁと。

OpenCVを使ってカメラの映像を顔認識をしてみる

開発

Python,OpenCV3を使ってカメラの映像からざっくり顔認識してみる。 Mac環境で、パッケージ管理はanacndaを利用。

インストール

brew install pyenv

$ xcode-select --install
$ pyenv install anaconda3-4.0.0
$ pyenv global anaconda3-4.0.0
$ pyenv rehash
$ pyenv version
anaconda3-4.0.0 (set by /Users/username/.pyenv/version)

env を設定

export PATH="$HOME/.pyenv/shims:$PATH"
export LC_ALL='ja_JP.UTF-8'

condaのアップデート

$ conda update conda
$ python --version
Python 3.5.1 :: Anaconda custom (x86_64)

OpenCV3のインストール

condaを使ってインストール。

$ conda install -c https://conda.binstar.org/menpo opencv3

エラーになる場合

libhdf5でエラーになる時がある。

Traceback (most recent call last):
  File "main.py", line 1, in <module>
    import cv2, matplotlib
ImportError: dlopen(/Users/username/.pyenv/versions/anaconda3-4.0.0/lib/python3.5/site-packages/cv2.cpython-35m-darwin.so, 2): Library not loaded: @rpath/libhdf5.10.dylib
  Referenced from: /Users/username/.pyenv/versions/anaconda3-4.0.0/lib/libopencv_hdf.3.1.0.dylib
  Reason: Incompatible library version: libopencv_hdf.3.1.dylib requires version 12.0.0 or later, but libhdf5.10.dylib provides version 11.0.0

libhdf5 をインストールしたりアップデートしたりする。

$ brew tap homebrew/science
$ brew install hdf5
$ brew search 
$ conda update libhdf5

OpenCVのバージョンを確認

python
>>> import cv2
>>> print(cv2.__version__)
3.1.0

必要なパッケージをインストールしておく。

$ conda install numpy matplotlib

カメラから映像を取り込む

cv2.VideoCapture() を使うとisightカメラをそのまま使える。

import numpy as np
import cv2

cap = cv2.VideoCapture(0)
cap.set(3, 640) # 横サイズ
cap.set(4, 480) # 縦サイズ

while(True):
    ret, frame = cap.read()
    if ret == False:
        break

    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # グレースケールに変換

    cv2.imshow('fram', gray)
    if cv2.waitKey(1) & 0xFF == ord('q'):
        break

cap.release()
cv2.dstroyAllWindows()
  • 毎フレームごとに読み込んで、cv2.imshow() に設定する

実行するとカメラの映像を白黒にしたプレビューが表示される。

送られてきた映像から、顔認識をする

パフォーマンスを気にしないで、ざっくりと顔認識を体験したいとする。 顔認識は、cv2.CascadeClassifier() を使う。

import numpy as np
import cv2

cap = cv2.VideoCapture(0)
cap.set(3,640)
cap.set(4,480)

cascade_path = "/Users/username/.pyenv/versions/anaconda3-4.0.0/pkgs/opencv3-3.1.0-py35_0/share/OpenCV/haarcascades/haarcascade_frontalface_alt.xml"
cascade = cv2.CascadeClassifier(cascade_path)
color = (0,0,255)

cnt = 0
while(True):
    ret, frame = cap.read()
    if ret == False:
        break
    else:
        if (cnt % 10) == 0:
            gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)
            facerect = cascade.detectMultiScale(gray, scaleFactor=1.1, minNeighbors=1, minSize=(1, 1))

        cnt += 1

        if len(facerect) > 0:
            for rect in facerect:
                cv2.rectangle(frame, tuple(rect[0:2]),tuple(rect[0:2]+rect[2:4]), color, thickness=4)

    cv2.imshow('fram', frame)

cap.release()
cv2.dstroyAllWindows()
  • 全てのフレームに cascade.detectMultiScale() をかけるとCPU負荷がかなりかかるので適当に10フレームごとに確認をする
  • cascade.detectMultiScale() はグレースケールの画像を使って精査する
  • 顔認識の結果を cv2.rectangle() を使って毎フレームごとに枠線を書き込むようにする

結果

f:id:taizo_onexone:20160627143923g:plain

仗助の顔を識別してくれない。

参考

postd.cc qiita.com

Webディレクターに求められるスキル

開発

Webディレクターに求められるスキルって最近多すぎるよなってことで自分なりにまとめてみた。

もちろん全部が必要あるわけではなく、ここら辺の内容を色々な職種が掻い摘んでいる状態なことが多い。

企画・設計力

  • 事前調査
  • 提案
    • ドキュメント作成
    • プレゼンテーションスキル
  • プロトタイプ周りの知識
  • 情報設計力

クライアントや意思決定者の話を聞いて、要件定義をしていく時に必要となるスキル全般。要求を聞くだけではなく、こちらから提案をする力も必要。そのためターゲットとなる市場の事前調査。さらに要件をまとめ上げるために、プロトタイプの制作も必要になったりする。このタイミングからでも、そのWebサービスがどのような設計になっているかを仕分けできるようになっていると後が楽になる。

プロジェクト管理スキル

  • 人員の確保
  • コミュニケーションスキル
  • 仕様書作成スキル
    • ドキュメント作成
    • プレゼン作成
  • コンセプト設計
    • サービスの文脈の整理
  • ワイヤーフレームの作成
  • プロジェクト進行管理
    • スケジュールの管理
    • 品質の管理
    • 費用の管理
    • 外注の進行管理
    • プロジェクト管理全般の知見

クライアントと協議して要件定義を決めて、制作や開発者チームに自分たちが何をしたいかを伝えるフェーズで必要になるスキル。まず誰に作ってもらうかの判断と確保が必要。その後、チームに何を作るかを伝える。その時にわかりやすく伝えるコミュニケーション能力や仕様書の作成能力、プレゼン能力も必要になる。また、コンセプトの設計をしっかりすることで仕様の確度を上げる。

制作が始まった後に、プロジェクトが問題なく動いているかを管理する。その場合にチケット駆動開発などのツールの知見が必要になる。チーム内の情報の流れ方、運用フローも決めたりする。また、この管理にはスケジュールだけではなく、品質、費用も含まれている場合もある。

プロダクトの開発

  • 法務周りの知見
  • Web業界の知見
  • 社内ルールの知見
  • コンテンツ制作
    • 中心となるサービス以外のコンテンツ作成
      • LPやバナーなど
  • QA
    • 手配 or 実行
  • 開発ツールを使いこなせるツール

開発に関連する周辺環境の知見。課金や個人情報の取り扱いなど、会社の法務とやりとりをしていくために必要な知見。アプリならば、App Store, Google Playのルール。特にApp Storeは何をしたらリジェクトされるかなどのルールも頭の中に入れておいたほうが良いことも。Webならば、SEOなどの流入の方法の必要最低限の知見も。それ以外に社内のルールも把握し、適切に立ち回れる。

また場合によっては、もともとデザイナーだった人がWebディレクターになることも無くはないので、簡単な制作物はディレクターが行う人もいる。

制作・開発が完成したプロダクトの確認・チェックをする場合もある。

また、最近開発で使われるツールは多い。チケット管理、ドキュメント管理、チャットツール、デザイン管理ツール（InVisionとか）など、開発者に合わせて習得する必要がある。ツールは日進月歩で進化して、開発者も移り気で使いたいものが変わることもあるので、それに追随が必要なこともある。

解析・運用

  • Google Analyticsやログなどのツールを扱うスキル
    • 計測の設計
  • どこに問題があるかを発展させる洞察力
  • 解析した結果から次のアクションに起こすための提案力

リリース後に、まず解析の基盤システムなどを使いながらも自分たちのプロダクトがどのような状態かを読み取れる力。それとどの部分に問題があるかを見つける洞察力。それと次のアクションを行うために、まわりを説得できるまでの提案力。小回りのきくいわゆるグロースハッカー的な力の場合や、クライアントや意思決定者への提案など粒度はさまざま。

これら全体をマネジメントをする力

  • コミュニケーションスキル
  • マネジメントスキル
    • 人・時間・お金の管理

企画から実現までのプロジェクトとPDCAを回す両方のマネジメントスキル。

もはや Webディレクターはコンサルである

第一線のプロがホンネで教える 超実践的 Webディレクターの教科書に

すでにディレクターへの期待値は「Webというマーケットを主軸としたビジネスのコンサルティング」に近い領域にまで達してきています。

と書いてあるけれど、もはや至る所でディレクターもはやコンサルみたいになっているみたい。

参考

標準ウェブ制作完全ガイド プランニングからデザイン、そしてシステム構築まで。Webの「仕事」がトータルに理解できるプロフェッショナル養成講座。

標準ウェブ制作完全ガイド プランニングからデザイン、そしてシステム構築まで。Webの「仕事」がトータルに理解できるプロフェッショナル養成講座。

第一線のプロがホンネで教える 超実践的 Webディレクターの教科書

第一線のプロがホンネで教える 超実践的 Webディレクターの教科書

web-tan.forum.impressrd.jp web-director.info

APIドキュメントを支える技術 2016

開発

qiita.com

1年くらい前に、APIドキュメントについて書いたけれど、最近また少し便利なことが増えてきている。

Swagger 2.0, API Blueprint が進歩してきている

Swagger – The World's Most Popular Framework for APIs. もライブラリが増えたり、エディタが進化したり、clientの生成が楽になったりと、ちょっと前に比べて使いやすくなってきている。

API Blueprintも Schema セクションを記述すればバリデーションにも使える。それにDockerもだいぶ浸透して、ドキュメント生成ライブラリのaglioのDocker imageも簡単に用意できる ので、生成の手間がものすごい減っている。

Validationは、ドキュメントにJSON Schemaを定義する

APIドキュメントに話を戻すと、ドキュメントの内容を使ってValidationをするときは、Swagger も API Blueprint も JSON Schemaを記載しておいて、テスト実行時にそれを使って検証をする。Swagger 2.0は、responseに記載が可能だし、Blueprint も上で書いたとおり、Schemaの記載ができる。

コードからドキュメントやクライアントを生成する

最近はコードから各種のクライアントライブラリを生成して運用するのでも問題ない状況になってきている。 https://github.com/goadesign/goa は、DSLめいた仕様を記載すれば、Goのモデル部分やswagger、jsのクライアントを生成してくれたりする。

それに grpc / grpc.io も浸透してきている。 これを導入できれば、Protocol Buffersを定義して、クライアントを生成して、それを呼び出し元に渡すという作業フローができる。API仕様書を各担当に渡して人の目で見て実装するという作業がだいぶ減る。

AWSのAPI GatewayもSwaggerサポート*1しているし、ドキュメントを書けばある程度サーバーの構築が完了し、後は裏のデータのやり取りなどの調整をするくらいになった。 どんどんサーバーアプリケーションサイドは楽になっていく。データの設計もクライアント側が考慮するようにすれば、サーバーアプリケーションサイドはほとんど必要もなくなるかもしれない。

*1:Swagger 定義ファイルを使用して API Gateway API をインポートおよびエクスポートする - Amazon API Gateway

コードリーディングの楽しみ方

開発

コードリーディングは大事なことだとよく言われているけれど、コードを読むというのは案外負荷がかかること。一方で自分が直接関与していないプロジェクトのコードやGithubにある有名なリポジトリとかを習慣的に読んだりしている人もいる。

自分はコードを読むという習慣がつかない方。良くはないよなぁと思いながらも、興味がついていかなかったりする。

なので、ある機会にコードを読む習慣がある人にどういう風に読むのか聞いてみた。

その人はREADMEを読んで、それを参考に全体をなんとなく読む。 あとはプルリクをみて、「この人、全然この人の修正にLGTMしないなぁ」とか「この人とこの人は流派が違うなぁ」とかを汲み取って楽しんでいるそうだ。

それとissueなどの議論をみたりするのも楽しいらしい。例えば、しばらく前に UnderscoreとLodashの統合*1 についての議論とかは、それぞれの作者がどのような意見でどういう行動をしているのかを眺めて、ライブラリの見方が変わったりすることもあるらしい。

それ 市況かぶ全力２階建 の楽しみ方と一緒じゃないか！って話になった。

kabumatome.doorblog.jp

*1:UnderscoreとLodashが統合に向けて議論

マイクロサービスでウェブサービスを構築するときにAPI Gatewayのことを頭にいれておいたほうが良いんじゃないか説

開発

新規開発でAWS ECSを使ったマイクロサービス構成でサービスを運用しているけれど、そこで学んだことのひとつに、API Gateway のことについて早い段階で考慮したほうがいいっていうのがある。 

ウェブサービスの新規開発の場合なら、最初はマイクロサービスで行こうぜってなったとしても、どれくらいトラフィック来るかもわからなかったり、スケジュールの制約もあるので、実際に細かく分けることはない。 

Client → App → DB

Clientが、ネイティブアプリだったり、ウェブページの情報取ってくるところ(Nodeやらウェブページやら)。App がいわゆるAPI。DBのデータを取ってきたり操作したりするところ。

最初にマイクロサービスっぽくなるところは、例えば検索機能とかあった場合に、Appから検索用のAPI(Search)を呼び出す場合。Searchでは裏で検索indexとかを作っているマイクロサービスとして見ることができる。

Client → App → DB
            `- → Search

こんな感じで機能がどんどん増えて行くと、Appがいろいろなところを呼び出すようになっていく。 

Client → App → DB
            `+ → Search 
            `+ → 機能1 
            `- → 機能2

すると、Appの存在が最初のモノリスティックな状態から、各機能から受け取ったデータをどう素早く取得して、適切な形式で返すかという機能に集中していくことになる。これがAPI Gateway になる。

なので、次第にAppとGatewayを分離したくなってくる。

Client → Gateway → App → DB
            `+ → Search 
            `+ → 機能1 
            `- → 機能2

このときに、初期のデータ設計で、分離された状態を想定できていなかった場合に、移行の難易度が跳ね上がる。もしくは、分離しても各マイクロサービス間でデータのやり取りが一気に増えてしまう可能性がある。 

依存関係の設計に頭を使おう

考えることは、どこまで並列に処理を実行できるかと、どこで情報の関連性を構築するか。これがデプロイにも影響するので、パッケージ管理も含まれる。これが意外とサービス発展の早い段階で着手する必要が出てくるので、もし最初からマイクロサービス的なアーキテクチャにしていこうとする場合は、頭に入れておいたほうがいいと思う。

参考

The Netflix Tech Blog: Optimizing the Netflix API