Goalist Developers Blog

IaC by Terraform ~DAY1: Preparation~

どうも,新卒エンジニアのナカノです.

今回はTerraformに関する記事です.

Terraformに関する第一回の記事はintroductiveな内容でした.

今回からは細かい部分に立ち入り,いくつかのパートに分けてお話しようと思います.

Day1の内容は,Terraformの実行環境の構築に関してです.

目 次
  • Installation   
    • For Windows
      • 1. Download a specific version of Terraform packages
      • 2. Extract the downloaded Terraform package
    • For Mac
      • 1. Install tfenv using Homebrew
      • 2. Install Terraform using tfenv
  • 最後に

Installation

For Windows

Windowsでのインストールだと,割と地道な感じになります.以下,その手順です.

  

1. Download a specific version of Terraform packages

最新のバージョンを使いたいならば,以下のページからパッケージをダウンロードしましょう. www.terraform.io

或いは,ある特定のバージョンをダウンロードしたいならば,下記の手順に沿ってダウンロードを行ってください:

  1. 上記URLの先のdownload older versions of Terraformという項目をクリックする.
  2. ダウンロードしたいバージョンの項目を選ぶ.
  3. 使用しているPCのOSを確認し,対応するパッケージを選んでダウンロードする.

  

2. Extract the downloaded Terraform package

ダウンロードしたものを適当な場所で解凍し,その後にterraformをパスの通った場所に配置すればよいです.

以下は,その作業方法の例です.

$ mv terraform_0.x.x_windows_amd64.zip path/to/src
$ cd path/to/src
$ unzip terraform_0.x.x_windows_amd64.zip
$ mv terraform path/to/bin

ここまでの作業が出来たならば,ホームディレクトリに移動してTerraoformのコマンドが実行できるかどうかを試してみましょう.

$ cd ~
$ terraform -version

バージョンが表示されれば,実行環境の構築は完了です.  

  

For Mac

Macの場合は,Homebrewを使ってインストールすることが出来ます.例えば,次の様にです:

$ brew install terraform 0.x.x

ただ,tfenvというTerraformのバージョン管理のツールがあるため,Macユーザーはtfenvを使ってTerraformをインストールしてみましょう.

  

1. Install tfenv using Homebrew

$ brew install tfenv

  

2. Install Terraform using tfenv

インストールの際に,Terraformのバージョンを指定する必要があります.

以下,バージョンの指定方法によるTerraformのインストールコマンドです:

1. A specific version
$ tfenv install 0.x.x
2. The latest version
$ tfenv install latest
3. The latest version matching regex
$ tfenv install latest:^0.x.x

なお,ここではtfenvについて詳細には立ち入りません.

詳しく知りたい方がいらっしゃいましたら,下記の参考ページを読んで頂けるとよいかもしれません. qiita.com github.com

最後に

実行環境の構築に関する話は以上となります.

Macユーザーの方には,是非ともtfenvを利用されることを推奨致します.

異なるバージョンをインストールする際には非常に便利ですので.

Day2以降では,Terraformの使い方Tipsなどをご紹介していこうと思います.

では,今回はここまでと致します.

デザインスプリント ~ DAY1 ~

こんちは。渡部です。
今回は社内外で行なっているデザインスプリントについて紹介します。
いつもの記事よりちゃんと書いたので長くなります〜

f:id:watabe1028:20180222160553j:plain

目次

 
 

デザインスプリントとは

米Google Venturesがスタートアップ支援の為に用いているプログラムで、
新規のアイデアをプロトタイプとして具体化し、
ユーザーテストを通じてアイデアの妥当性や効果の検証を行うもの
です。
(間違った認識だったらご指摘ください)

詳しくはこちら

 
今回は時間がないのでDAY5を3日間で行うプログラムを選択しました。
そしてスプリントの対象は弊社サービスの「HRogチャート」です。
改善点が多い、伸びしろしかねぇ!サービスです。
 
 

きっかけ

きっかけは個人的にデザインスプリントに参加できる勉強会などを探していたところ
ワークショップを開催している会社さんがあったので
速攻で問い合わせを投げました。
 
興味あった人がちらほらいたので
そのメンバーでやれれば良いかな、と思っていたら
社員の半分近くが参加することになってましたw

 
そして今回はその会社さんにファシリテーターをして頂いてのスプリントです。
株式会社ISAOのお二人にファシリテートして頂きます。

www.isao.co.jp

性格の良い会社」に選ばれている企業で、
海外でもデザインスプリントに参画している腕利きの方々です。
今回はなんと14人も参加だったので2チームに分けて同時にスプリントを回します。
(本当は5人くらいがベストです)

 

STEP1 Discover 発見

ここでのゴールは
f:id:watabe1028:20180222162224p:plain
です。

 
次にHRogチャートの中長期ゴールを書き出し
このスプリントのゴールも設定します。
またHRogチャートの歴史をCTOから話してもらいました。 f:id:watabe1028:20180222163210j:plain
 
HRogチャートの前バージョンの開発者でありゴーリストCTOに
開発の背景や苦労話をしてもらいます。
ゴーリスト内でも業務上、HRogチャートに触れずにいるメンバーもいます。
この話を聞くことによって
今まで関わってなかったメンバーも自分ごととして意識できるようになります。多分。
 
次にユースケース作成です。
ここから2チームに分かれ、それぞれ進めていきます。
 
こちらのチームはこんな感じ。

f:id:watabe1028:20180222163422j:plain

こちらはこんな感じ

f:id:watabe1028:20180222163441j:plain
視点がそれぞれのチームで違い、
”1つの課題”が別物になりそうです。
 
 
次にユーザーテストを行います。
既存のサービスを操作してもらい
ユーザーの操作、表示を観察します。
 
今回は社内のHRogチャートを操作したことがない社員に操作してもらいました。
このテストは別室で行いユーザーに緊張を与えないように注意します。
 
ディスプレイからユーザーの動向を観察し
それぞれの気づきをポストイットに書き込んでいきます。
 
ポジティブな気づきは右上に「P」を
ネガティヴには「N」をつけて書いていきます。
ここはポストイットの色で分けるのもありです。
(実はポストイットを1色しか用意してなかったとは今更言えない)

f:id:watabe1028:20180222163729j:plain
Nがいっぱいw

 
次にHow might me メソッドを用い
複数の角度から解決の方向性をあげます。
 
「私たちはどうしたらxxxな体験を良い体験にできるだろうか?」
f:id:watabe1028:20180222164424p:plain 
 
HRogチャートで言うとこういった角度があります。
f:id:watabe1028:20180222164518p:plain 
それをマップに当てはめていきます。
 
それをみんなでそれぞれ評価します。
いいね、と共感できる問題にシールを貼っていきます。
これが大事!となる問題には大きいシールを貼ります。
 
これが終わるとヒートマップができます。  
 
 

STEP2 Realization 見える化

ここから個人の作業になります。
テキストメモ、マインドマップ、ラフスケッチなど
自由に検討し
UIスケッチとしてアウトプットします。
f:id:watabe1028:20180222165449j:plain  

 
3枚ほどのストーリーUIを書き出し、
キャッチーなタイトルをつけます
その周りには補足コメントなどをつけ
何を意図しているか伝わるようにします。
f:id:watabe1028:20180222165551j:plain

 
 

STEP3 Decision 決定

全員のアイデアを壁に貼り
ポストイットと同様にシールをつけて投票していきます。
投票の際は相談はやめましょう。
他の人の意見に惑わされず
自分の良いと思ったアイデアにどんどん投票します。
 
またポストイットもそうですが
誰がどのアイデアを出したかを
なるべくわからないようにしましょう。
権限や個人的に付き合いのある人を
無意識に高評価してしまうことがあります。
 
ここで最も良い!と思ったアイデアには
大きいシールを貼ります。
大きいシールは1人2つだけです。
f:id:watabe1028:20180222172130j:plain
f:id:watabe1028:20180222172152j:plain
 
最後にDecider(決定者)が1つのアイデアを決めます。

ここでの注意点は
シールの多いアイデアを選ぶ必要はありません
シールが一つもないアイデアでも
Deciderがこれだ!と思ったアイデアを選びます。
 
Deciderが一つアイデアを選んだら
このアイデアを考えた人に説明をしてもらいます。
ここでチーム全体でアイデアを共有します。
 
 
ここからまたチーム作業です。
選んだアイデアからストーリーボードを作成して
どのようなプロトタイプを作るか決めていきます
ここがあやふやだとプロトタイプを作成をするデザイナーがキレます。
f:id:watabe1028:20180222172327j:plain
 
今回は2チームあるのでお互いのストーリーボードを見せ合い
どちらのアイデアでプロトタイプを作るかを決めます。
今回はこちらのチームのプロトタイプを作成することに決まりました。
f:id:watabe1028:20180222172255j:plain

 

DAY1 まとめ

デザインスプリント、結構疲れます
普段使わないような頭の使い方、
立ったり座ったり、話したり作業したりを
時間を設定して、シビアにアウトプットを出して行くので
なかなかあっという間です。
 
デザインスプリントの良いところは
プロダクトを良い方向に持っていくだけではなく、
普段あまりコミュニケーションを取らないメンバーも
遠慮なくディスカッションが出来るところにある
と思います。
 
DAY2はプロトタイプ作成とインタビュー作成です。
プロトタイプはデザイナーの腕の見せ所です。
インタビューは普段お客様と接しているセールスチームの意見が貴重になります。
それぞれの強みを活かしあって、プロダクトを良くしていく。。。
これ、めっちゃ楽しいです!

 
 

おまけ

やっぱりデザイナーのイラストなどがあると捗るね、と話していたところ
俺もあれくらい書けるよ!と言ったCTOの絵です。
狂気を感じます。。。
f:id:watabe1028:20180222173603j:plain

Selenium WebDriverでスクリーンショットを撮る

こんにちは ゴーリスト開発のモリツグです

Selenium WebDriverで画像キャプチャが必要になった時、Firefoxだとスクロールで見えない部分まで撮影できるのに、Chromeだと見えている部分しか撮影してくれません。
この問題を解決してくれる便利なライブラリaShotのご紹介です。
言語はJavaです。

aShotの使い方

まずは以下のReadMeを参考にpom.xmlをかいたり、直接jarを落としてきたり好きな方法でaShotを使えるようにします。

github.com

Mavenリポジトリのリンクはこちらです

以下のような感じで撮影してファイルに書き出せばよいと思います。

private void captureImage(WebDriver driver, String filePath, float quality) throws IOException {
    JPEGImageWriteParam param = new JPEGImageWriteParam(Locale.getDefault());
    param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
    param.setCompressionQuality(quality);
        
    // 150はミリ秒でスクロールを待つ時間、短すぎるとダメな模様
    ShootingStrategy ss = ShootingStrategies.viewportPasting(150); 
    // スクロールせずにそのまま撮影したい場合は以下
    // ShootingStrategy ss = ShootingStrategies.simple();

    Screenshot screenshot = new AShot().shootingStrategy(ss).takeScreenshot(driver);

    ImageWriter writer = null;
    try {
        writer = ImageIO.getImageWritersByFormatName("jpg").next();
        writer.setOutput(ImageIO.createImageOutputStream(new File(filePath)));
        writer.write(null, new IIOImage(screenshot.getImage(), null, null), param);
    } finally {
        if (writer != null) {
            writer.dispose();
        }
    }
}

複数の画像を連結したい!

aShotとは直接関係はありませんが、複数の画像を1枚につなげて保存したいという要望があると思います。
画像サイズは同じであるとして、以下のような感じでできます。(厳密には横のサイズが1枚目と同じ前提)

private void createAllImage(WebDriver driver, String filePath) throws IOException {
    ShootingStrategy ss = ShootingStrategies.viewportPasting(150); 
    
    driver.navigate().to("https://www.google.co.jp/");
    BufferedImage image1 = new AShot().shootingStrategy(ss).takeScreenshot(driver).getImage();
    
    driver.navigate().to("https://goalist.co.jp/");
    BufferedImage image2 = new AShot().shootingStrategy(ss).takeScreenshot(driver).getImage();
    
    JPEGImageWriteParam param = new JPEGImageWriteParam(Locale.getDefault());
    param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
    param.setCompressionQuality(1.0f);
    
    List<BufferedImage> captureList = new ArrayList<BufferedImage>();
    captureList.add(image1);
    captureList.add(image2);

    int entireHeight = 0;
    for (BufferedImage imageBuf : captureList) {
        entireHeight += imageBuf.getHeight();
    }
    BufferedImage entireImage
        = new BufferedImage(captureList.get(0).getWidth(), entireHeight, captureList.get(0).getType());

    ImageWriter writer = null;
    Graphics entireGraphic = null;
    try {
        entireGraphic = entireImage.getGraphics();
        int tempHeight = 0;
        for (BufferedImage imageBuf : captureList) {
            entireGraphic.drawImage(imageBuf, 0, tempHeight, null);
            tempHeight += imageBuf.getHeight();
        }
        writer = ImageIO.getImageWritersByFormatName("jpg").next();
        writer.setOutput(ImageIO.createImageOutputStream(new File(filePath)));
        writer.write(null, new IIOImage(entireImage, null, null), param);
    } finally {
        if (writer != null) {
            writer.dispose();
        }
        if (entireGraphic != null) {
            entireGraphic.dispose();
        }
    }
}

まとめ

ブラウザに関係なくお手軽にスクリーンショットが取れるaShotが本当に便利でした。
スクロールバーは出ているけれど、このパターンの時はスクロールしなくていいなぁみたいな時にShootingStrategyでスクロールさせない方法が指定できるのも使いやすかったです。

【知ってるようで知らない】AWS EC2インスタンスのしくみ

こんにちは、ゴーリスト開発の飯尾です

最近AWSからこんなお知らせが来てなんじゃいと思いましたが
どうやらとあるインスタンスがもうすぐ死んでしまうらしい

f:id:y-iio:20180213162724p:plain

このあたり見るにつけ

docs.aws.amazon.com

qiita.com

ルートデバイスタイプがEBSなので、いったんインスタンス停止して開始したらOK〜

はい

よく考えたらルートデバイスタイプって何?なんで再起動したらOKなの?

EC2インスタンス日々使っているくせに
どういう仕組みで動いてるのかはぜんぜん知らなかったので調べてみました

そもそもEC2ってなんだ

EC2ってなんだ
仮想のサーバーをゾンアマさんから借りれるしくみだよ

インスタンスってなんだ
借りた仮想のマシンだよ
ホストコンピュータの一部分を一つのマシンとして扱うよ
ここではホストコンピュータ君の一部に肉体の型と魂を与えて一つのマシンとみなすよ

f:id:y-iio:20180213163049j:plain:w300

リージョンってなんだ・アベイラビリティゾーンってなんだ
ホストコンピュータが物理的に置いてある国・地域の分別のことだよ

f:id:y-iio:20180213163109j:plain

AMIってなんだ
インスタンスを作るためのテンプレートだよ
アマゾンマシンイメージの略だよ
マシンの肉体の型だよ

f:id:y-iio:20180213163135j:plain

EBSってなんだ
マシンのデータ置き場のひとつと思っておこう
ここではデータ=魂ということにするよ

f:id:y-iio:20180213163202j:plain:w300

肉体の型と魂さえあればどのホストコンピュータ上にも同じマシンを作れるよ

ルートデバイスタイプってなんだ

インスタンスはテンプレートを使って起動されるよ

昔はテンプレート置き場がS3にあって、インスタンス起動のたびに
それぞれのホストコンピュータのインスタンスストアにそれをコピってきて使っていたよ
データボリュームはその都度ホストコンピュータ上に作られているから
インスタンスを停止したらデータは失われるよ
「ルートデバイスタイプがインスタンスストア」っていうのはこういうことを言うよ

f:id:y-iio:20180213163241j:plain

今ではEBSというしくみがあって、
EBSベースに作られたテンプレートを使って、EBSに置いてある魂を紐づけて使ったりするよ
インスタンスを停止してもデータはEBS上に残るよ
「ルートデバイスタイプがEBS」っていうのはこういうことを言うよ

f:id:y-iio:20180213163305j:plain

docs.aws.amazon.com

なんで再起動したらOKだったんだ

ゾンアマさんからきた死亡宣告は、
「今動いてるインスタンスのホストコンピュータが調子悪いぜ!」
と言う意味だったよ

f:id:y-iio:20180213163422j:plain:w300

なのでいったん停止してまた起動し直すことで
別のホストコンピュータ上でインスタンスが起動したからOKになったよ

f:id:y-iio:20180213163357j:plain:w300

はい

「正解率」でモデルを評価することは危険(かもしれません)!

こんにちは、ゴーリストのチナパです! 機会学習の中によくあるクラシフィケーション問題を作りながら必ず「正解率」と出会うでしょう。しかし、アルゴリズムを評価する方法は他でもあります。ここにはいくつかを調べて見ます。

まず、問題を定義しましょう。簡単な可塑的な問題です。10人の中、誰が赤が好き、そして誰が青いが好きを何かの情報を見て予想したい設定を使います。 つまり、一番の人から10番の人まで、「赤」か「青」というラベルを付けたいということになります。

f:id:c-pattamada:20180208192435p:plain

では、こんな結果がでたとしましょう。 一番自然な評価は正解率だと思いますので、まずはそこを見ていきましょう ここは7回●、3回✖️なので、正解率は70%ですね。

ただし、よく見るとこのアルゴリズムが青を全然よく判断してありません。それは、もしかして青が少数だからかもしれませんが、この問題をもっとひどくした場合に こういうことも見れます。

f:id:c-pattamada:20180208192502p:plain

ここも正解率70%です 単なる毎回「赤」と言っているじゃないですか、こんなことをするたみにアルゴリズム作る必要もないです。 70%正しいでも、本当の状況について何も行ってくれません。

これは正解率の弱点です、クラス(この場合、赤と青)の割合がほぼ同じだった場合なら問題ないかもしれませんが現実の世界では 数が多いクラスと数が少ないクラスが大抵のものです。

では正解率より良い方法があるのでしょうか?

一つの方法は正解と間違った率に加えて偽陽性と偽陰性の割合も見ることです。 自分は辞書から探し出した言葉なので説明します(難しい言葉がどうかわかりません) 「赤」の偽陽性はアルゴリズムが「赤」だと思ってて間違ってた時 「赤」の偽陰性はアルゴリズムが「赤」ではないと思ったが実は赤でした時

2番目の例には、青の偽陰性が100%なので一目で問題があるとわかります。 1番目の例の場合の詳しい計算をします、都合よくするためにもう一回貼ります

f:id:c-pattamada:20180208192435p:plain

赤: 答えた数:8 実は赤だった数:7 正解数:6 偽陽性数:2 偽陰性数:1 こんな感じでも表せられます。

f:id:c-pattamada:20180208192539p:plain

こういう情報も分類するモデルの作成の時にとても便利です。(緑は正しかった時、オレンジは間違ってた時.....ここも赤と青使ってたら混乱しますねw)

では、比べられるために一つの数値で表せられませんか? 様々な方法があると思いますが、私は便利だ思うのはf-value (か、f1-value)と言われます。

(precision・精度) = 偽陽性数 / 答えた数 = 2 / 8 => 25%
(recall・再現率)= 正解数 / 実は赤だった数 = 6 / 7 => 86%

赤の再現率はアルゴリズムが「赤だ」ということをどれだけ上手く予想できるかを測る数字 赤の精度はアルゴリズムが「赤ではない」ということをどれだけ上手くわかるかを測る数字

この両方は高ければ、アルゴリズムが「赤」をよく予想できると言えるでしょう。 では、どう組み合わせますか?

f-valueは精度と再現率の調和平均です。

つまり

f-value = 1 / ((1 / 精度) + (1 / 再現率))

この場合の赤のf-valueは39%です。 ちなみに、青のf-valueは40%です。それぞれのクラスのf-valueの平均をとればアルゴリズムのf-value を表せます。この場合、はもちろん40%以下です、70%の正解率をみるより焦りますね。

f:id:c-pattamada:20180208193402j:plain

(写真はbimbimkhaより)

Angularでenvironmentsの中身をいじって環境毎に変数の中身を設定したい

おはようございます。バンナイです。 Angularでenvironmentsの中身をいじって環境毎に変数の中身を設定したいです。

動機

今度新しく作るステージング環境で呼び出すAPIを既にある本番環境で呼び出すAPIとは別にしたい。

デプロイしたい環境に応じてAPIのURLを手作業で書き換えることもできる。

しかし、environmentsの中身をいじればビルドをする際のコマンドを変えるだけでそれが実現できると先輩から教えてもらったのでそれを試してみます。

作業

environments配下にファイルを作成、編集

src/environments 配下に environment.staging.tsを作成。中身は

export const environment = {
  production: false,
  apiUrl:"staging環境でのurl"
};

environment.dev.tsの中身は

export const environment = {
  production: false,
  apiUrl:"dev環境でのurl"
};

environment.prod.tsの中身は

export const environment = {
  production: false,
  apiUrl:"prod環境でのurl"
};

それぞれ以上のようにします。

.angular-cli.jsonの内容を編集

environmentsのところの内容を以下のようにします。

"apps": [
    {
     ・・・略
      "environments": {
        "dev": "environments/environment.ts",
        "prod": "environments/environment.prod.ts",
        "staging": "environments/environment.staging.ts"
      }
    }
  ]

environment を import

変数を利用したい箇所でenvironment を importしたり等。 今回はテストのためにapp.component.tsで環境毎に中身が変わる変数を用意して、変数の中身をapp.component.htmlで画面に表示して、環境毎に変数の中身がちゃんと書き換わっていることを確認します。

app.component.ts

・・・略
import {environment} from "../environments/environment";
・・・略
export class AppComponent {
  public apiUrl = environment.apiUrl;
・・・略

app.component.html

<p>{{apiUrl}}</p>

確認

ローカル環境で確認してみます。

ng s --env=dev
ng s --env=prod
ng s --env=staging

で動かしてみて、それぞれ画面に

dev環境でのurl

prod環境でのurl

staging環境でのurl

と表示されたらオッケーです。

f:id:bbbbbbbbb9:20180208134351p:plain

実際にデプロイする時は

ng build --env=staging

等とすればデプロイしたい環境に応じて、コードを書き換えることなく、変数の中身を変更できます。

統計・マーケ・機械学習 Meetup! #4 @ ゴーリスト

そういえば,数か月ぶりの執筆担当だ....

お久しぶりです.新卒エンジニアのナカノです.

今回は,ゴーリストオフィスで行われた勉強会のレポートを書こうと思います.

勉強会のテーマは「統計・機械学習」です.

目 次
  • 勉強会の概要
  • 何はともあれ、まずはカンパーイ!
  • LTの内容
    • 1. 使えるデータの作り方
    • 2. DBスペシャリストに合格して自由を手に入れた話
    • 3. AICについて
    • 4. 統計検定を受けてみた
    • 5. pythonとmatlabを使った最適化とこれから読みたい本
    • 6. GoogleのAI分析の結果を、実地で確かめてみた
    • 7. 機械学習初心者が短期間でTensorFlowで作ったMNISTモデルをAndroidアプリに組み込んだ話
    • 8. IT勉強会開催の進めと「続ける」技術
    • 9. ピクトさん量産計画
    • 10. 分析手法紹介
  • 締め括り



勉強会の概要

以下のURL先のページに,勉強会の概要が書かれております.一度ご覧頂ければと思います. data-refinement.connpass.com



何はともあれ、まずはカンパーイッ!

Meetupということで,飲み食いしながら様々なLTが堪能出来る形式となっております.

さてさて,まずは各自飲み物を持って,せーの......カンパーイッ!

f:id:r-nakano:20180125015027j:plain

思いの外参加者が多く,その分だけこれから始まるLTの発表に胸が高鳴るナカノでした.

お~,ドキがムネムネッ!(某クレヨンし○ちゃんのネタ)



LTの内容

各LTの発表のまとめを,self-containedな形で以下に与えておこうと思います.

1. 使えるデータの作り方

f:id:r-nakano:20180125155328j:plain

主に,データの必要不可欠さとデータの加工に関することを発表されておりました.

何事においてもデータは必須であり,それを有効活用するためには「必要な時に必要な形」でデータが使える様にする必要があります.

そのために,CrawlingやScrapingという技術を用いてデータの加工整形が行われます.


2. DBスペシャリストに合格して自由を手に入れた話

f:id:r-nakano:20180125022557j:plain

発表によると,即戦力になるためにはやはり少なくとも資格を取得しておいた方が良いとのことです.

ですがその一方で,mqtsuo02さん自身が様々な業務を経験してきた結果から,資格の取得だけでなく「自分次第な部分を変えるための実践」も非常に大切だと説いていらっしゃいました.


3. AICについて

f:id:r-nakano:20180125135827j:plain

相関係数の話から発表は始まり,次第にAICに関する様々なツールや概念を概説されていらっしゃいました.

その時,聴講者たちはどんな表情をしていたのでしょうか...?

f:id:r-nakano:20180125140752j:plainf:id:r-nakano:20180125140801j:plain

おっと,何とも言えない表情をされていらっしゃるゾ....


4. 統計検定を受けてみた

f:id:r-nakano:20180125135915j:plain

cougarさんの「フリーランスになった経緯」から「統計検定を受けた時の状況」などについて,発表されておりました.

統計や機械学習がビジネスで活かせそうだとcougarさんは考えており,特に「顧客サービスの休止ユーザーに関する分析」への応用に期待していらっしゃるそうです.


5. pythonとmatlabを使った最適化とこれから読みたい本

飛び込みLTの発表その1です.発表者のmoritaさんは「人工衛星により捉えた生物の住む森林のエリアの画像を分析し,そのエリアの面積の変化を調査する」ということを行ってらっしゃるそうです.

その際にpythonやmatlabを使った最適化処理を実施されているのですが,現状ではデータ分析の方法や手順や方法が確立されているが分析精度の大小などは評価しづらいとのことです.

それ故にデータを観察し想定や着想などを持つことが大事であり,それは機械学習の利用においても言えることであるそうです.

また,発表の最後にオススメの関連書籍を紹介されておりました.


6. GoogleのAI分析の結果を、実地で確かめてみた

飛び込みLTの発表その2です.発表内容は,Googleの「スマートクッキー」プロジェクトに関するものでした.AI分析の結果として出力されたレシピは非常にシンプルでした.

AIの判定を実験的に確かめるため,そのレシピをもとにいざ作ってみたそうです.結果ですが,レシピに改善すべき点が幾つかみられました.

判明したことですが,AIのアウトプットは業務に落とし込む部分の手前のものなので,やはりその様な部分で人の役割は必要不可欠であるということです.


7. 機械学習初心者が短期間でTensorFlowで作ったMNISTモデルをAndroidアプリに組み込んだ話

発表内容は「数字が写っている画像を認識して正解の数字を特定するアプリの開発」に関してです.

開発の際に,Kerasという「Tensor Flowなどをバックエンドとしたニューラルネットワーク用ラッパーライブラリ」を使用しているとのことです.

まえすとろさんによれば,Kerasは初学者でもアプリ開発で何とかなる有能なツールだそうです.


8. IT勉強会開催の進めと「続ける」技術

発表によると,IT勉強会の開催のメリットとしては「勉強会はやりとりや知識・認識の共有がしやすい環境であるため,参加する意義がある」とのことです.

また,継続は力なりということも説いていらっしゃいました.

例えば「30日間をどのように続けるか?」とか「反抗期、不安定機、倦怠期などの作業継続が困難になりがちなフェーズに陥った場合,如何にして乗り越えるか?」などの話がありました.

聞いているうちに,継続は力なりという言葉は非常にシンプルだが大変重要だなと再認識しました.


9. ピクトさん量産計画

写真からのピクトの生成に関して発表されておりました.

ピクトの生成の際にDeep Learningによるポーズ推定が行われており,その結果として「画像にある人のポーズから様々なピクトの生成が可能」となっております.

ポーズ推定ですが,対象が一人或いは複数人の場合のそれぞれで推定を行います.

複数人の場合は,まずはそれぞれの部分を切り取り,そこから先は「一人の場合の推定方法」を使って推定が行われます.

推定の実験の中で,何故か大阪のグリコの画像からはピクト変換出来なかったそうです.


10. 分析手法紹介

最後の発表は,様々な分析手法の紹介に関してでした.発表の中で

  • 数理最適化(近藤次郎(最適化))、探索問題(近藤次郎(最適化))
  • 応用待ち行列(本間鶴千代(待ち行列の理論))
  • 世論調査モデル(深尾毅(分散システム論))
  • 昇給報酬モデル(羽鳥裕久(有限マルコフ連鎖))

といったものが紹介されていました.



締め括り

以上が,勉強会で発表された内容のまとめでした.各々のまとめの内容に凹凸があり,非常に稚拙なまとめとなってしまいました.

ただ,勉強会の状況や様子をお伝えすることは出来たかなと思っております.

私は現在インフラ関連の業務を行なっておりますが,統計・機械学習・関数型言語の分野にも興味があるため,分野に囚われずに積極的に勉強していければと思います.