PHPerKaigi 2018前夜祭に行ってきた(前前夜祭のLaravel Meetup Tokyo #10にも行ってきた)

phperkaigi.jp

PHPerKaigi 2018前夜祭

PHPerKaigi 2018の前夜祭に行ってきました。
最近色々な人からコミュニティへの貢献の大事さという話を聞くことがあって、ノリと勢いでサポーターとして登録しました。
普通が4000円でサポーターが8000円、前夜祭だけでもビールが出たりTシャツがついていたりと+4000円でも文句なしなんじゃないかと思いました(まだ明日の本番があるけど)。

PHPerが集まるカンファレンスとしては、秋にPHPカンファレンスが開催されています。
PHPerKaigiは初めての開催で、Kaigiという名前からも分かる通り、スピーカーの方が一方的に話すのではなく、聞く側からの反応(双方向のコミュニケーション)も大事にしていきたいというお話でした。

トーク

PHPでテスティングフレームワークを実装する前に知っておきたい勘所 - @tadsan

niconare.nicovideo.jp

PHPでテスティングフレームワークを0から実装されたお話でした。
ミニマムな要件から段階的に実装されていく流れは聞いていて面白いなと思いました。
コードも公開されているようです。

github.com

ライブラリとフレームワークの違いとして、フレームワークプログラマが書いたソースコードを呼び出すもの、とおっしゃっていたのは初めて知ったので面白かったです。
フレームワークは作れるよ、というまとめと、現実のアプリケーションのテストをするにはフレームワーク以外でもセッション管理やDB層など色々考えることが多いよね、という問題提起で締められていました。
言語を学ぶときにテスティングフレームワークがよい、という話を聞いてことがあるので今度なにか違う言語でやってみたいと思いました。

PHP と SAPI と ZendEngine3 と - @do_aki

www.slideshare.net

PHPの現場というPodcastの第17回を聞いて、PHPの中の話をされるということを聞いて、楽しみにしていたトークでした。
はじめのSAPIや、Zent Thread Safety、Zend Engineの話などをされていて、はじめのあたりはすごくわかりやすくて、なるほどーときいていたのですが 、すべてのテーマで途中から全くついていけませんでした。泣
しかしながら、他のかたもTweetされていたのですが、非常によくまとまっていた資料および発表ということだったので、あとで復習したいと思います。

大統一PHP - @uzulla

speakerdeck.com

Apache + mod_php や Nginx + php-fpmなど、PHPの環境構築がややこしいという話で、PHP単体でhttpdになれればその環境構築もよりわかりやすくなるよね、やってみた!というお話でした。
PHPの内部やその周辺のニッチ(?ぼくにはそう見えた)な技術を色々紹介しつつ、その目的を達成していく、という流れはハック感がかなりあってすごく面白かったです。

1つ前のdo_akiさんのトークと呼応している部分もあるように感じてこの辺で内部が分かればもっと面白いんだろうなという気持ちになりました。

また、トーク内容とは異なるのですが、発表者のuzullaさんは何かのイベントで司会をされたこともあるということで、話の煽り方、トーンダウンがすごくて、あまりわからないながらも引き込まれて聞けました。

まとめ

総括として、かなりレベルが高くて(特に少しレイヤーが低い話が多くて?)ついていけない感はあったものの、普段触っていても意識しない部分について詳しい方々の話を聞けるのは良い機会でした!
明日(出す頃にはもう今日ですが)の本番はDBの話も多かったり、裏トラックでPHPの現場の公開収録やLaravel、CakePHP相談会などの企画もあったりするので、楽しみです!

おまけ

Laravel Meetup Tokyo #10

また、その前夜にあったLaravel Meetup Tokyo #10にも出席しました。
LT枠が空いていたので、「Eloquentの使い方を考え直した」というタイトルで発表してきました。

speakerdeck.com

正直なところ、皆さんの発表のレベルが高く、自分のあまり練習できていないLTが気になって、緊張しすぎて良く内容が入ってこなかったです。汗

ただ、テストの話が多く、皆さんそこに共通の悩みを持たれているのだな、という風に思いました。
あと、スポンサーさんのリブセンスさんが提供の転職DRAFTビールが美味しかったです。
10回目開催、おめでとうございました!

laravel-meetup-tokyo.connpass.com

【Vue.js】リッチなUIのWEBアプリに必須なドラッグ・アンド・ドロップの実装

f:id:zuckey_17:20180304215932g:plain

WEBアプリケーションでリッチなUIを実現したい場合、内部的には複雑な操作を簡単そうに見せるためのひとつの工夫として、Drag and Dropは必須と言ってもいいと思います。
今回、Vue.jsとそのライブラリのVue.Draggableを利用して、簡単にリストのDrag and Dropを実現することができたので、紹介したいと思います。

本エントリに記載しているソースコードは以下にあります。

github.com

デモ => https://zuckeym-17.github.io/vue-dnd/

Vue.Draggable

Vue.DraggableはSortable.jsというJavaScriptでリストの Drag and Dropを実装するためのライブラリをベースに開発されています。
そのため、なにかやりたいなと思ったときは、Sortable.jsのドキュメントをあたったほうが、知りたかった情報が書かれていたりします。

Vueの基本的な説明は省略します。
画面の都合上、.vueファイルのstyleタグも省略しています。

また、コード中で利用しているListItemというコンポーネントは、単なるリストの1要素です。
liタグの中にspanタグを配置し、ドラッグハンドルとして使っています。

<template>
  <!-- spanタグをドラッグハンドルとして利用、dragHandle Propsがtrueのときのみ現れる -->
  <li><span v-if="dragHandle" class="drag-handler">:::</span>{{ item }}</li>
</template>

<script>
import Vue from "vue";

export default Vue.extend({
  props: {
    item: String,
    dragHandle: false
  }
});
</script>

1列のリスト

基本的な1列のリストを作成します。
Vue.Draggableをdraggableでインポートして、element属性を変更しているだけです。

<template>
  <div style="margin: 50px;">
    <p>1列リスト</p>
    <!-- Vue.Draggableのコンポーネントを利用。
    ListItemは li なので、レンダリング時の要素を ul にするため element 属性を設定 -->
    <draggable element="ul">
      <!-- list を v-for で 回す。
      key属性については、 https://jp.vuejs.org/v2/guide/list.html#key を参照。 -->
      <list-item
        v-for="item in list"
        :key="list.indexOf(item)"
        :item="item"></list-item>
    </draggable>
  </div>
</template>

<script>
import Vue from "vue";
import ListItem from "./ListItem";
import draggable from "vuedraggable"; // Vue.Draggableのコンポーネントをインポート

export default Vue.extend({
  components: { draggable, ListItem },
  props: ["list"]
});
</script>

与えられている listは以下のようなものです。

const list = [
  "トレイン=ハートネット",
  "スヴェン=ボルフィード",
  "イヴ",
  "リンスレット=ウォーカー"
];

複数列のリスト

複数列間でDrag and Dropを実現します。
Vue.Draggable コンポーネントは、options属性にオブジェクトを渡すことで色々な設定ができます。
ここでは、group オプションを指定し、Drag and Dropで要素を 複数列に渡って行き来させることができます。

<template>
  <div style="margin: 50px;">
    <p>複数列リスト</p>
    <div style="display: flex">
      <!-- options 属性に オブジェクトをbind
      board を v-for で 回す。 -->
      <draggable
        :options="options"
        element="ul"
        v-for="list in board"
        :key="board.indexOf(list)"
      >
        <!-- 1列リストのときと同様 -->
        <list-item
          v-for="item in list"
          :key="list.indexOf(item)"
          :item="item"></list-item>
      </draggable>
    </div>
  </div>
</template>

<script>
import Vue from "vue";
import ListItem from "./ListItem";
import draggable from "vuedraggable";

export default Vue.extend({
  components: { draggable, ListItem },
  props: ["board"],
  data() {
    return {
      options: {
        group: "board", // group オプションを指定した draggable 間はDrag and Dropで要素を移すことができる
        animation: 100 // animationオプションを指定すると ソート時に 値(ms)で アニメーションされる
      }
    };
  }
});
</script>
const board = [
  [
    "セフィリア=アークス",
    "ベルゼー=ロシュフォール",
    "エミリオ=ロウ",
    "クランツ=マドゥーク"
  ],
  [
    "ナイザー=ブラッカイマー",
    "アヌビス",
    "ジェノス=ハザード",
    "バルドリアス=S=ファンギーニ"
  ],
  [
    "デイビッド=ペッパー",
    "リン=シャオリー",
    "ベルーガ=J=ハード",
    "メイソン=オルドロッソ"
  ]
];

追加可能なリスト

リストであれば、要素を追加したかったりします。

<template>
  <div style="margin: 50px;">
    <p>追加可能なリスト</p>
    <draggable element="ul">
      <list-item
        v-for="item in list"
        :key="list.indexOf(item)"
        :item="item"
      ></list-item>
      <!-- slot="footer" をつけると、リストに並ぶ異なった要素を入れることができる。
      入力された値を、addItem メソッドによってリストに追加していく。 -->
      <div slot="footer">
        <input type="text" v-model="input"/>
        <button @click="addItem">Add</button>
      </div>
    </draggable>
  </div>
</template>

<script>
import Vue from "vue";
import ListItem from "./ListItem";
import draggable from "vuedraggable";

export default Vue.extend({
  components: { draggable, ListItem },
  props: ["list"],
  data() {
    return { input: "" };
  },
  methods: {
    // addItem メソッドを定義しておく
    addItem: function(e) {
      e.preventDefault();
      this.list = this.list.concat(this.input);
      this.input = "";
    }
  }
});
</script>

ドラッグハンドルを指定したリスト

ドラッグするときのツマミを指定して、他の要素には別のイベントを仕込みたい場合などがあります。
その時は handle オプションをつけます。

<template>
  <div style="margin: 50px;">
    <p>ドラッグハンドルありのリスト</p>
    <draggable
      element="ul"
      :options="options"
    >
      <!-- list-item に dragHandle Propsを渡して、ドラッグハンドルを表示させる -->
      <list-item
        v-for="item in list"
        :key="list.indexOf(item)"
        :item="item"
        :dragHandle="true"
        ></list-item>
    </draggable>
  </div>
</template>

<script>
import Vue from "vue";
import ListItem from "./ListItem";
import draggable from "vuedraggable";

export default Vue.extend({
  components: { draggable, ListItem },
  props: ["list"],
  data() {
    return {
      options: {
        // handle オプションによって、リストの中でつかめる要素を指定することができる
        handle: ".drag-handler"
      }
    };
  }
});
</script>

まとめ

Vue.Draggableを利用して、簡単にドラッグ・アンド・ドロップを実現することができました。 オプションや、ドラッグ開始時、ドロップ時の各種制御方法は以下のページに記載されているので参考にしてみてください。

github.com

関連

blog.zuckey17.org

Storybookをまず動かす!ReactとVueの最小環境を作った

最近Storybookを会社で導入していて、環境設定についてまとめました。
基本的には、公式サイトのとおりですが、コンポーネントの例の記載がなかったり、ReactとVueでできるものが異なったりして、困った部分が合ったので、すぐに動く環境を作りました。

github.com

本エントリのコードはNode v8.9.4の環境で動作を確認しています。

Storybook?

f:id:zuckey_17:20180222101257p:plain

https://storybook.js.org/

The UI Development Environment

ReactやVueなどのUIライブラリで作成したコンポーネントの動作やデザインをエンジニア、デザイナ間で共有、閲覧できるツールです。
Storybookという名前の通り、あるコンポーネントコンポーネントの集合に対して、storyを複数用意し、storyごとの振る舞いを閲覧することができます。

環境構築

StorybookはReact、Vueの場合それぞれ、内部的にWebpackを利用しています。
このエントリで紹介しているものを動かすためには特別な設定は必要ありませんが、必要に応じてWebpackの設定をすることもできます。

Storybook - Custom Webpack Config

f:id:zuckey_17:20180222041649g:plain

動くサンプルはこちら↓

https://zuckeym-17.github.io/storybook-sample

Reactの場合

1. プロジェクトフォルダを作成、npm init

mkdir storybook-sample
cd react-storybook-sample
npm init

2. StorybookとReactについて必要なライブラリを追加

@storybook/reactおよび、reactreact-dombabel-coreを追加する必要があります。

npm i --save-dev @storybook/react
npm i --save react react-dom
npm i --save-dev babel-core

3. Storybookの環境を立ち上げるnpmスクリプトを追加

{
  "scripts": {
    "storybook": "start-storybook -p 9001 -c .storybook"
  }
}

ここでpacage.jsonの全容は以下のようになります。
https://github.com/zuckeyM-17/storybook-sample/blob/master/react-storybook-sample/package.json

4. Storybookの設定ファイルを作成

Storybookは設定ファイルを.storybookというディレクトリに置きます。
最小環境では、Storybookにstoryの場所を伝える設定を.storybook/config.jsに書くだけです。
以下では、stories/index.jsを読み込むという設定をしています。

import { configure } from '@storybook/react';

function loadStories() {
    require('../stories/index.js'); // 好きな場所のstoryをrequireできます。
}

configure(loadStories, module);

5. Reactのコンポーネントを作成

ボタンの中身と、クリック時のメソッドをPropsとして渡せる単純なコンポーネントを作成します。
components/Button.jsxとして以下を保存します。

import React from 'react';

const Button = ({onClick, children}) => {
  return (
    <button onClick={onClick}>{children}</button>
  );
};

export default Button;

6. storyを作成

ここまでいけばあとはstoryを書くことができます。
ストーリーはいわば、そのコンポーネントの初期状態です。

import React from 'react';
import { storiesOf } from '@storybook/react';
import { action } from '@storybook/addon-actions';
import Button from '../components/Button';

storiesOf('Button', module)
  .add('with text', () => (
    <Button onClick={action('clicked')}>Hello Button</Button>
  ))
  .add('with some emoji', () => (
    <Button onClick={action('clicked')}>😀 😎 👍 💯</Button>
  ));

7. Storybookの起動と確認

これで準備は完了です。
以下のコマンドにてStorybookを起動し、localhost:9001にアクセスしてみましょう。

npm run storybook

Vueの場合

1. プロジェクトフォルダを作成、npm init

mkdir storybook-sample
cd vue-storybook-sample
npm init

2. StorybookとVueについて必要なライブラリを追加

@storybook/vueおよび、vuebabel-coreを追加する必要があります。

npm i --save-dev @storybook/vue
npm i --save vue
npm i --save-dev babel-core

3. Storybookの環境を立ち上げるnpmスクリプトを追加

{
  "scripts": {
    "storybook": "start-storybook -p 9001 -c .storybook"
  }
}

ここでpacage.jsonの全容は以下のようになります。
https://github.com/zuckeyM-17/storybook-sample/blob/master/vue-storybook-sample/package.json

4. Storybookの設定ファイルを作成

Storybookは設定ファイルを.storybookというディレクトリに置きます。
VueのStorybook最小構成では、

  • Storybookにstoryの場所を伝える設定: .storybook/config.js
  • Storybookに用意されているaddonを使う宣言: .storybook/addons.js

をそれぞれ用意する必要があります。

.storybook/config.js

stories/index.jsを読み込むという設定をしています。

import { configure } from "@storybook/vue";

import Vue from "vue";

function loadStories() {
  require("../stories/index.js");
}

configure(loadStories, module);

.storybook/addons.js

@storybook/addon-actionsという、イベントハンドラのコールバック関数として設定し、そのイベントが発火したことをロギングするためのaddonを利用する旨を設定します。

import '@storybook/addon-actions/register';

5. Vueのコンポーネントを作成

ボタンの中身と、クリック時のメソッドをPropsとして渡せる単純なコンポーネントを作成します。
components/Button.vueとして以下を保存します。

<template>
  <button @click="handleClick">{{ children }}</button>
</template>

<script>
import Vue from "vue";

export default Vue.extend({
  props: ["handleClick", "children"],
});
</script>

6. storyを作成

ここまでいけばあとはstoryを書くことができます。
ストーリーはいわば、そのコンポーネントの初期状態です。

import Vue from "vue";
import { storiesOf } from "@storybook/vue";
import { action } from '@storybook/addon-actions';
import MyButton from "../components/Button.vue";

storiesOf("Button", module)
  .add("with text", () => ({
    components: { MyButton },
    data() {
      return {
        handleClick: action("clicked"),
        children: "hello button"
      };
    },
    template: '<my-button :handleClick="handleClick" :children="children"></my-button>'
  }))
  .add("with some emoji", () => ({
    components: { MyButton },
    data() {
      return {
        handleClick: action("clicked"),
        children: "😀 😎 👍 💯"
      };
    },
    template: '<my-button :handleClick="handleClick" :children="children"></my-button>'
  }));

7. Storybookの起動と確認

これで準備は完了です。
以下のコマンドにてStorybookを起動し、localhost:9001にアクセスしてみましょう。

npm run storybook

まとめ

ReactとVueで同じStorybookが動くサンプル環境を作ってみました。
コードベースも基本的に記事中のものが全てですので、是非一度動かしてみていただければなと思います。

おまけ

グローバルなCSSなど

Reset CSSなど、コンポーネントに当てるCSSとは別にグローバルになにかコンテンツを読み込んでおきたいということがあると思います。
その際は、設定ファイル置き場である.storybookpreview-head.htmlを作成し、HTMLのheaderに追加したいタグを書くことができます。

例)Reset CSS、Font AwesomeのJSをCDNから利用する

<link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/3.18.1/build/cssreset/cssreset-min.css">
<script defer src="https://use.fontawesome.com/releases/v5.0.6/js/all.js"></script>

日本初!?運用のノウハウがつまったRedash Meetup #1に参加した

redash-meetup.connpass.com

@ariarijp さんと、@kakakakakku さんが運営されているRedash Meetup #1に参加してきました。
僕は年始から会社でRedashを導入していて、MySQLAWS Aurora)と Elasticsearchをデータソースとして運用しています。

日本初のRedash Meetup!?

Redashについて、以前から名前は知っていましたし、昨年12月、今年の1月と続いてハンズオン会などが開催されていたりしたものの、ユーザーなどが集まってRedash単体の話をするような勉強会は僕が調べた限り始めてだったのではないかと思います。(間違っていたらすみません)
そういう会に参加できてうれしかったです!

会自体は2人の方の20分ほどの発表、5分 * 2のLTという構成でした。
19時半開始、20時45分解散というすごく健全な勉強会でした。

発表

Redash 導入事例から考える OSS BI ツール導入チェックリスト - ariarijp

speakerdeck.com

ariarijpさんが働かれているSNS広告を運用をされている会社さんでの導入の経緯や利用され方、困った点を紹介した後に、同様のユースケースではBIツールにどういう要素を求めるのか、ということを話されていました。
こちらの会社では、広告運用の中で日々出てくるデータ抽出作業をすべての人に開放するためにRedashを使われている、ということでした。
業務上、重要な作業をRedashが担うということになったがゆえにRedashのパフォーマンスが業務効率に大きく寄与するようになり、その上でメンテナンス性をBIツールに求めるべきという話と、実際の運用のノウハウなどの紹介も面白かったです。

ジモティーでの Redash 活用事例 - kyoshidajp

speakerdeck.com

ジモティーさんでは、Redashの利用者が40人でクエリ数が2300クエリあるということでした。
比較的大規模に使われている、ということでユーザー管理のGoogle認証連携とそれに付随するOSSとしてのRedashへの貢献についての紹介も面白かったです。

また、少し早めに発表が終わったこともあって、Q&Aの時間が長くあったのですが、その中で、クエリの管理の方法についての議論になっていてそれが面白かったです。
クエリが多くなりすぎると検索しづらくなるという問題があるという話で、たしかに僕の会社でも導入して1ヶ月足らず程度にも関わらず、50近いクエリができているので棚卸しが必要だなと思いました。
参加者の方々は、すでに運用されていた方も多いようで、ディスカッションの中でこの問題への対処方法が紹介されていました。

  • Redash管理層のDBから使われていないクエリを抽出して、スプレッドシートに削除対象リストとして公開
  • クエリのDiscriptionの部分にタグのようなものを書いておいて、検索性を上げる

LT 僕と Redash と Athena - dyuju_you

S3にためたログやデータをAthena経由で抽出、分析したいというときに、無邪気にクエリを打つと

  • Redashのリソース
  • ブラウザ性能
  • Athenaの課金

の観点で色んな意味で死んでしまうという問題をRedashにおけるAthenaのデータソースのコードをカスタマイズして仕組みで防いだという話でした。

OSSだからソースコード読めば良いという話をされていましたが、僕は完成度高そうなツールのコードを読みに行って改善するのって大変そうだなぁと漠然と思っていたので、
データソースのコードに絞って手を入れて、ツールの中のコードに手をいれて改善する良い事例紹介だったのではないかなと思いました。

LT Redash ユーザーのための Metabase 入門 - manabusakai

speakerdeck.com

Redash Meetupでは挑戦的な、別のOSS BIツールであるMetabaseの紹介LTでした。

  • インターフェースの美しさ
  • SQLを書かずに分析ができること

Metabaseはより簡単に、早くデータ可視化、分析をできるようにしたツールで、
Redashのように多くのデータソースやそれらをまたいだ分析などをコードで解決できるというツールとは、対象ユーザーが違う、という話をされていました。

まとめ

Redashを会社に導入して思ったのは、ダッシュボードやグラフ化などの可視化の機能が見栄えが良いのでそこに意識が向きがちで、様々なデータソースにアクセスができてjoinできるという点をうまく活用するのは、データのありかや意味がわかっているエンジニアばかりになってしまうということでした。
可視化して美しいダッシュボードを作るのは夢のある話だな思いますが、まずは日々のデータ抽出から始めて、エンジニア以外の人も巻き込んでやっていくのがよいというのは、いろいろな方がおっしゃっており、地道にやっていくしかないのだなと思いました。
その中でパラメータによって誰でも使えるクエリをたくさん作る、など少しでもRedashを触るハードルを下げる取り組みはもう少し積極的に社内でも推し進めていこうと思いました。

また、今回、OSSとしてのRedashへの貢献であったり、ハックであったりの事例も多く話されていたように思います。
先程も書きましたが、そういう貢献はハードルが高そうに思えていました。
こういう勉強会の場でその事例が紹介されていると、アプローチの方法がぼんやり浮かんできそうで、その辺を意識してツールを触れたら良さそうだなと思いました。

最近導入して、たくさん触っているというのもあって、総じてすごく良いイベントでした。運営のお二方ありがとうございました!!

おまけ

今回の運営の一人である@kakakakakku さんが公開されているハンズオン資料を実施して、ブログで紹介していたり

blog.zuckey17.org

WEBエンジニア勉強会#05にて導入して少したったタイミングでの所感などを話しています。

speakerdeck.com

メモ

以下、勉強会中のメモです。

Redash導入事例から考えるOSS BI導入チェックリスト

@ariarijp

ユニトーン(SNS広告の運用) ariarijp.hatenablog

ユニトーンにおける導入事例

導入以前

データ抽出は社内ツール、SQL

=> ツールの魔改造EXCELによるデータ加工 => データ抽出へのリードタイム

導入の経緯

  • クエリのFork
  • APIで扱える

導入後の変化

  • パラメータ変換を使うなどして、データ抽出の制限がなくなった
  • 抽出結果の共有がスムーズ
  • 集計結果をREST APIで加工できるので集計結果を入力としたプログラムで、データを二次利用

大変になったこと

  • 複雑な集計クエリが大量に
  • 今までにないデータを集計対象にしたいという要望
  • Redashが業務の中心になり、業務効率に直結 => 棚卸しが必要

チェックリスト

前提: エンジニアは10人

  • データ抽出がしたい
  • エンジニアの工数削減
  • コストをかけたくない

誰が使うかを考える

非エンジニアも使える?
BIツール導入と併せて、データに係る知識の底上げをエンジニア主体で行う

どのDBを参照するか?本番、レプリカ?
ネットワーク上どこに置くか?
可能であれば集計用DWHに逃がすのが吉? => BigQuery、Redshift、TDなど

運用

  • Ubuntupython、nginx、Redis、PosgreSQLの知識
  • サーバーのモニタリング
  • 設定のチューニング、公式ドキュメント

まとめ

  • 誰が使うか?エンジニアが巻き込む
  • データ基盤の整理
  • 安定運用できる知識が必要

ジモティーでのRedash利用事例

kyoshidajp

40人でクエリ数が2300
PostgreSQLからメタデータも簡単に取れる

基盤

mongoDB、Aurora

↓ embulk

Redshift、BigQuery // BigQueryのほうが安くてよい?

dry runモードというのがあって、料金を抑えたりする

利用事例

アカウント管理

  • Google認証の導入
  • セキュリティグループによる制限

データ抽出

BigQueryの場合はユーザ定義関数も使える
Pythonデータソース

Redash社内勉強会

パラメータが便利

まとめ

OSSなので不満や、こうなれば便利というのがあればPRを投げる

僕と Redash と Athena

dyuju_you

Hadoopが好き

webpage tracking
nginx golang
fluentd
s3

データソースは2つ
- presto => hadoop - athena => s3

無邪気なクエリ

  • Redashの死 => * 使うな!!
  • ブラウザの死
  • お金の死 (Athena高い、1クエリ/500$)

どうする?

システム的に何とかするのが吉
OSSだからソースコード読めば良い

  • Limit制約
    • 一定のLimitを付けないとだめ
  • Pertition制約

スキャン量を減らす

Glue Data Catalog

怖くないSQLライフを

Redash ユーザーのための Metabase 入門

manabusakai

Metabase?

  • シンプル、かんたん、早くアクセス
  • セットアップが簡単
  • SQLいらず
  • 美しいダッシュボード

blog.manabusakai.com

GUIからSQLができる?

  • 異なるData Sourceのjoinが出来ない
  • Data Sourceがやや少ない

ターゲットユーザーが違う
エンジニアチームにはRedash、分析チームにはMetabase

Redashとは補完し合うツール
権限管理はMetabaseのほうが良い

Inside Frontend #2に参加してきた

Inside Frontend

inside-frontend.com

大手町日経カンファレンスルームで開催されたINSIDE FRONTENDというカンファレンスに参加してきました。
2回めの開催ということですが、僕は今回が初めての参加でした。

どういうカンファレンスだったか

「Web フロントエンドの現場とこれからをつなぐカンファレンス」ということで、主なスポンサーのCyber Agentさん、日本経済新聞社さん、YAHOO!さんを中心に各現場でのノウハウがたくさん聞けました。
このカンファレンスでは、一般的な講演形式の「セミナー」と、質疑応答形式の「AMA(Ask Me Anything)」が並行しており、AMAではみなさんが普段どのような悩みを持っておられるのか、どのへんに引っかかりポイントがあるのかが、よりわかって良かったです。

やり取りのログは、運営の方がいかにまとめてくださっています!すごいです。

GitHub - insidefrontend/issue2-ama: AMA ブースで聞いてみたい質問をこの Repo の Issue として Submit ください(どなたでも!)

また、当日のセッションのビデオもFRESH!さんにアーカイブされています。(生放送もされていました。)

freshlive.tv freshlive.tv

このエントリでは、僕が参加したセッションをベースに感想を書いていきます。
カンファレンス中に書いたメモもこちらに残しますが、あくまでメモなので、上記のビデオや、公開されている資料、AMAは上記githubにまとまっているので時間がある方はそちらを参照される方が良いと思います。
実際に参加して現場感を感じたり、知り合いと会ったり、質問したりというのが良いですが、すべてログに残っているのは素晴らしいです!

セッションの感想

以下感想です。

freeeのアクセシビリティ、いまとこれから - @magi1125 (AMA含む)

docs.google.com Issues · insidefrontend/issue2-ama · GitHub

freeeにおけるアクセシビリティの意識を上げていくときの取り組みの紹介と現状、これからの方向性についての紹介でした。
アクセシビリティチェックリストの紹介や実際にどのようにコードに落としていくかなど技術的な話もありましたが、僕はかなりエモい話だったなと感じました。

正直、アクセシビリティを意識してのプロダクト開発というのをそこまで意識していなかったので、新鮮に聞くことができました。
アクセシビリティというものを、デザインの問題、凝ったアニメーション、などそういったもので 間違って認識していたので改めました。(じゃあアクセシビリティが何なのか、というのは僕の言葉ではうまく説明できる気がしないので、資料を参照ください。)

作るサービスによってアクセシビリティが重要視されるかどうか、必要性が議論されるべきというのは、僕も感じることがありました。
例えば担当している法人向けの管理画面などは、定常運用をいかに効率化するか、間違いがなく運用できるようにするか、などが重要視される、といったような違いがあげられるかと思います。

現場の ES201x とアーキテクチャの変遷と未来 - @mizchi (AMA含む)

speakerdeck.com Issues · insidefrontend/issue2-ama · GitHub

題名通り、フロントエンドのこれまでのアーキテクチャ変遷から、未来を予測すると言った話でmizchiさん節がすごかったです。
僕は現在プロダクションコードとして存在するレベルのjQueryしか知りませんが、ざっくりとこれまでのことを理解できましたし、現状のフロントエンドのライブラリ、フレームワークを大枠で捉えたときにEventとStateとViewを完全に分離するというのは、そうですよねと思って聞けました。

WebComponentsの話や、今のWeb標準とPWAの関係*1などについてもお話されていました。

とはいえ、一番面白かったのはじゃあどうやって現状のものをきれいにするのか、というところでした。
まずやるべきこととしてprettierを入れたり、lintを入れたり、型をつける作業をしたりとかなり泥臭いところからやっていくということで、フリーランスでいろいろな現場を見られているかたがそのように段取りを提示してくださるのは良いなと思いました。

コンポーネントTDDの実践から見えたもの - @pirosikick

www.slideshare.net

ReactとVueにおいてコンポーネントを作成するときにTDDを導入する話。
TDDとは関係のないコンポーネントのテストを書くときのハマりどころから、TDDを導入する際の注意点と、今後の改善点を説明してくださっていました。
TDDについてはTDD本を読んでいたので、目的や良さなど理解できていたように感じました。

コンポーネントのテストということで、デザイン変更のたびに頻繁に変わりうるUIのテストをどこまで書くのかという議論があるのではないかと思っていたのですが、セッションを聞いていてTDDでやるとコンポーネントのテストを見た目とふるまいを分離して書けるのかもしれないなと思いました。
セッション中に紹介されていた以下の資料も参考になりそうでした。

slides.com

動的デザインガイドのつくり方 - @narirou

speakerdeck.com

モノリシックなフロントエンドのアプリケーションをデザインガイドラインを適用するための開発プロセスと、各ステークホルダーとの調整方法をまとめて話してくださっていました。
Design Systemという概念やそれが具体的にどういうものだったのかということはいまいち理解しきれなかったのが残念だったのでもう少し他の資料も当たってみたいと思います。

Micro-benchmarking is Hard - @saneyuki

docs.google.com

開発中にベンチマークを取る際ときに、しっかりと意味のあるベンチマークを取らないと根拠のない数字から可読性の低いコードを生産してしまう可能性があるよ、という話でした 。
具体的には、
大きな(マクロな)機能のベンチマークを取る場合はその機能の使われ方内部の実装をしっかりと理解しなければならないために難しく、
じゃあちいさな(マイクロな)機能のベンチマークはどうなのかというと、利用しているJavaScriptエンジン(今回はフロントエンドの話なので)の最適化の実装によって期待しているような結果が得られない可能性があるので難しいということでした。

結局、エンジンの内部実装を理解して最適化されにくいようにベンチマーキングするのか、ベンチマークする単位をある程度複雑にして最適化されにくくするのかというような結論だったのではないかと思います。
ふわっと思います、と書いたのは、このセッションが僕にはかなり難しかったからです。
もう少しJavaScriptに詳しくなってから、資料を読み返したいと思います。

まとめ

かなり遅くなりましたが、Inside Frontend #2の感想記事を書きました。
現在、業務にてStorybookの導入を勧めているため、今回のInside Frontend#2ではUIコンポーネントのデザインや設計についてのセッションを多く聞きました。
アクセシビリティベンチマークなどは初めての話が多く、興味を惹かれたので、優先度付けて深ぼれたらなと思いました。

*1:こちらはデブサミで詳しく話されるようです。

続きを読む

物理の可視化で楽しくカイゼンを回しているヴァル研究所に遊びに行った

ヴァル研究所(以下、ヴァル研)さんに遊びに行ってきました。

www.val.co.jp

f:id:zuckey_17:20180209174211j:plain:w300

サービスとしては、「駅すぱあと」などで有名ですが、ある一方では会社全体で、アジャイルおよびアジャイルのプラクティスを導入され、業務改善にすごく良い感じで取り組んでおられることで有名な会社さんです。

遊びに行ってきた聞いたきたこと、感想などをメモ的に残しておこうと思います。

何をしに行ったのか

f:id:zuckey_17:20180209174251j:plain:w200

有名なスライドで、↓のようなものがあるのですが 、

www.slideshare.net

この発表者のぷぽさん id:pupupopo88 と面識があり、

について事例を見たり、それについて議論したりするという目的で見学に行ってきました。

公開できない情報が記載されていたので、KPTボード、リリーストレイン、カレンダーボード、スプリントボードなどは写真に収めてこれなかったのが残念です。

中の人のブログがあって、物理ボードの雰囲気などは伝わるかなと思っています。

hiiiiiiihikaru.hatenadiary.com

KPTについて

KPTは振り返りツールで、

  • Keep=よかったこと
  • Problem=悪かったこと
  • Try=次に試すこと

の頭文字を取っています。

僕が所属する開発チームでも導入していましたが、「T」が消化されず、意味を見出せなくて立ち消えてしまったという経緯がありました。

話しているうちに、継続させていくにはいくつかポイントがありそうだなと思いました。

物理でやったほうが良い

ヴァル研さんは本当に物理ボードが多く、いろいろなことを物理的に可視化されています。 その中でもKPTは物理でみんなで囲みながらやった方が良いとのことでした。

ワイワイやるのが大事

KPTで振り返りを始めます」といっても、業務が忙しかったり、やり方に馴染みがなかったりすると辛いというメンバーがいたりします。
そういったことを解消するには、楽しく続けて、習熟させていくということが重要ということでした。
KPTでよく言われるのは「ちょっとくだらないことをあげて発言のハードルを下げる」、というテクニックですが、同じ感じで始めはKを多めにして、より楽しくするということが重要なようです。

PをPのままで放置しない

「やるやら」をまず決める、対応するものをTに落としてマトリクス化(重要度と難しさを軸にする)することが重要とのことでした。 やらないものについては2種類あって、

  • 大した問題ではない
  • 大きな問題すぎる

後者は、別で深掘りするための会議などを設けるといったTにすることが重要とのことでした。
大きすぎる問題について、Tを無理やり作ってしまうと、結局重い問題だけが溜まってしまうというのは僕のチームに起こった問題に近いかもしれないと感じました。

また、「やるやら」や、やらないことの大きさの判断については、本当の課題を見出す技術などが重要というのがありました。
そういったことに長けた外の人を呼んだりしつつ、併せて技術力を磨いていくしかない、ということでした。

リリーストレイン + カレンダーボード + スプリントボード

この3つのボードが、ヴァル研の多くのチーム(特に開発関係)で導入されていたように感じました。

規模の順に リリーストレイン => カレンダーボード => スプリントボード という関係性です。

基本的には

  • リリーストレイン
    • 半年間の大まかなスケジュール(半月単位で見直しあり)
  • カレンダーボード
    • 月1のものリリーストレインからブレイクダウンしたやること、イベント
  • スプリントボード(カンバン)
    • 1週間(1スプリント)単位でのタスクとそのポイント

という風に分類をされているようでした。

すべて物理でやられているところも多かったのですが、開発チームについては、PRとタスクを紐付けたり、リモートワークに対応するためにスプリントボードのみデジタルにされているチームが多いということでした。

また、スプリントボードのタスクはそれぞれに、

  • やる理由
  • ゴール
  • 大まかな方法

を書くことをルール付けされていました。 粒度や書き方などは修正すれば良くて(例えば小さすぎるタスクには何も書かれていなかったりしていました)、徹底することよりも、始めること、それを続けることが大事なのだな、という印象を受けました。

その他

開発以外のチームで導入する良さ

純粋に、そのチームの業務が改善するということ以外にもメリットがあるようでした。
開発以外とも含めたチーム間でアジャイル用語や、アジャイルのプラクティスの言葉が伝わるという状況はかなり嬉しいということでした。
確かに、開発には「それは優先順位低いから次のスプリントでやりますね。」というので伝わることも、営業さんやその他のビジネスサイドの方には、違う言い方をしないと行けないのは積もるとコストなのかなとも思いました。
共通言語の本として、SCRUM BOOT CAMP THE BOOKを導入されていて、一時期購買の書籍購入履歴がそればかりになったという話もされていました。

VSM(Value Stream Mapping)*1

僕も初めて知ったのですが、VSMというものが、開発島の至る所に貼ってありました。
僕のかんたんな理解では、開発にかかった時間を可視化することで、どこのプロセスにどれだけの時間がかかっているかを可視化し、効果が高いタスクや改善ポイントを見極めることができる、といったものです。
いろいろな壁に貼ってあるのをざっくりと眺めて、サービスの流れが見えるような気がしたので、本来の目的だけではなくサービス全体を見渡す意味でも良さそうだなと感じました。
また、ヴァル研では、そのプロセスを誰が担当していたかということも書かれており、その部分に詳しい人もわかりやすくなっているのも良さそうでした。

物理ホワイトボード、壁が豊富

自社ビルということもあり、広く、(開発以外も)1チーム5~10人に2枚ずつくらいのホワイトボード があり、さらに壁際に基本的に机がなく、壁がフリーでした。
壁一面をホワイトボードして活用されているところも多かったので、僕の会社にはない感じだなと思いました。*2

物理での可視化は、

的な意味で良いなと思いました。
自社ではどのように実現するのか、物質的な問題は個人では解決が難しいなと悩ましいところだと思いました。

週の真ん中に振り返りをやる

スプリントレビューについてもKPTも週の真ん中にやるのが良いということでした。
理由としては、金曜日になると疲れも溜まって生産性が下がったり、ネガティブな意見が多くなったりするとのことです。
水曜午後1が一番のおすすめポイントらしく、なんとなくキリがいいというだけで週の最後にしていましたが、それだけで雰囲気が良くなるなら即採用なんじゃないかなと思いました。

まとめ

とりとめのないものになってしまいましたが、今回の見学では、「圧倒的な物理の可視化とその維持のノウハウがすごかった」、という印象でした。
組織にアジャイルの概念、プラクティス、そしてカイゼンの文化を導入しようとしたのは、上からのお達しだったらしいですが、それを受けて社員のみなさんがしっかり続けられていたのがすごいなと思いました。
真面目な人間性がそれを実現している、という話をされていまたが、それ以上に本当にカイゼンが必要だと思って、ちょっとつらくても明るく楽しそうにカイゼンしていく人がいたからこそなんだろうな、と思いました。

今回僕は非公式に個人としてでお邪魔させていただきましたが、ヴァル研では会社単位などでも公式に職場見学を受け入れておられるそうです。

お招きいただいたぷぽさんも、 DMにて、

何かを変えたいと思ったとき、特に組織的な事の場合はひとりでやるのはやっぱり厳しくって、仲間を見つけた方がいいです。今はいなくても、仲間にしたい人、なってくれそうな人。

そういう人と会社見学に来ると、また違ったものが得られると思います。(ということもあり、昼間に会社単位で見学、現場の生の声を聞いてもらってます)
(原文ママ)

というふうにおっしゃっていたので、検討してみてはいかがでしょうか? 実物見るとすごいと思います。

PR

ぷぽさんは僕がパーソナリティを務めているPodcastでもアジャイル関連の話をしていただいているので、よかったらそちらも聞いてみてください。

*1:cf. https://qiita.com/i35_267/items/1c2d75861b55c537f1e0

*2:バーンダウンチャートが物理になっているのはすごいなと思いました。

感想とメモ | WEBエンジニア勉強会 #5@ITプロパートナーズイベントスペース 20180202

OSCAさんの主催されているWEBエンジニア勉強会#5に参加してLTもしてきました。 その反省と他の方の発表の感想を書きます。

web-engineer-meetup.connpass.com

OSCAさんは僕がパーソナリティをしているしがないラジオでもゲスト出演されています。勉強会を主催しようと思った経緯なども話されているので、興味があれば聞いてみてください。

また、会の様子はtogetterにまとまっています。

togetter.com

参加者の構成

ノージャンルということもあって、おなじみとなっている、会の参加者の構成の発表がありました。*1

経験年数

年数 人数
0~1年 12人
1~3年 13人
3~5年 7人
5~10年 12人
10年~ 9人

仕事の分野

分野 人数
サーバーサイド・プログラマー 27人
サーバサイド・アプリ基盤エンジニア 11人
フロントエンドエンジニア 15人
フロントエンドデザイナー 12人
WEBディレクター/プロジェクトマネージャ 6人
インフラ・ネットワークエンジニア 7人
スマートフォンアプリエンジニア 3人
その他 8人

経験年数については、10年以上の人はまとめられてしまっていますが、短い人から長い人まで同程度の分布なのかなと思います。
分野については、サーバーサイドが最も多いですが、その他はまばらにいらっしゃるようでした。ただ、WEBエンジニア勉強会と銘打っているのでスマートフォンアプリエンジニアは少なかったのだな、という印象でした。

自分の発表

Redashの導入とチームをまたいだ変化の話

speakerdeck.com

最近、会社にRedashというOSSのデータ可視化ツールを導入しそこで変わったこと、良かったことを話しました。 内容は資料のとおりなのですが、反省としては次のようなことが挙げられたかなと思っています。

  • 具体例を上げてもう少し詳しくRedashについて紹介すべきだった
  • (時間的に巻いていたとはいえ)かなり早口で喋ってしまった

社内のものだったので具定例を多く書けなかったということもあるのですが、イメージを持っていただくためにももう少し時間があれば環境を作って、例示できれば最高だったなと思いました。

他の方の発表

HTTPレイヤーで行うパフォーマンスチューニング(@engineer_osca)

speakerdeck.com

主催であるOSCAさんの発表です。
これまで通り初心者向けのテーマを選びながらも、実際に動くところまでをデモされているのが素晴らしいです。
年末年始に自分の趣味のプロダクトで試してみた、というエピソードも話されてましたが、サンドボックス的に触れる自分のプロダクトを持つのはすごく良いなと思いました。

とにかく分かりづらいTwelve-Factor Appの解説を試みる(@suke_masa)

www.slideshare.net

僕は知らなかったのですが、クラウドで動くアプリケーションが従うべき12個のベストプラクティスというのがTwelve-Factor Appらしいです。
こういう宣言とか定義みたいなものは、一読してパッと理解できるものというよりは例があったり実際に困ったりしたことがないとわからなかったりするな~という印象です。
発表で、「こういうときありますよね?」「こういうときどうですか?」などと問いかけをしてくれると理解が深まるな、と思いました。

なにか作ったらプレスリリースを出そう(@binbin4649)

www.slideshare.net

サービスのPRをするための戦略を話してくださいました。
あまり聞いたことがない話で興味深く聞けたのと、最後に「PRバズーカ」というサービスのPRをされていて進め方がうまいな〜と思ったりしました。

Amazon Rekognitionを用いてフォロワーの男女比を出す(@kzkohashi)

speakerdeck.com

顔認識のAPIを利用した事例の紹介でした。
SNSのフォロワーをアイコンの顔認識で分析するというのは事例としてかなり面白いなと思いました。
またそういう画像認識APIの各クラウドサービス間の比較を行った話や、意外と安く使えるといった話まで、知ってはいつつも触れていない僕にはすごく興味深い発表でした!

Dockerを利用したローカル環境から本番環境までの構築設計(@kkoudev)

www.slideshare.net

Dockerについて利点や、なぜこうしたほうが良いのか、というのを丁寧に解説してくださいました!
Twelve-Factor Appの話と合わせて聞くと「なるほど~」感が強かったです。

非機能要件を考えてみよう!(@iwanaga0918)

昨今のセキュリティの問題やosushiさんの話*2も例に、非機能要件について、定量的にちゃんと考えていますか、という問いかけの話でした。
発表者の方が、SIerということで、IPA非機能要求グレードをチェックリストとしてやると良い、と言った話もされていました。
もちろんサービスごとにいろいろな側面がありそうですが、非機能要件がある程度定量的に指標化されてチェックリストになっているのは嬉しいんじゃないかなと思いました。

まとめ

WEBエンジニア勉強会は5回目ですが、僕は#1,2,3,5と参加していますが、大規模でなく2時間くらいの規模の勉強会で、テーマをあえて絞らず、幅広い分野の話が一気に聞ける勉強会はなかなかないので面白い試みだな、と思います。

主催者のOSCAさんが、いろんな人に発表されているので、暖かく迎えてくれている感もあって発表しやすい空気があったと思います。

コミュニティとしてもっと活発にしたい、という話もあったので、会のあとにその場でビアバッシュなどがあるともっと交流ができたりするのかなとも思ったりしました。

次回、4月初旬頃に1周年の会があるらしく、日程が合えば是非参加したいなと思いました。

*1:connpassのアンケート機能で調査されています。

*2:https://togetter.com/li/1195320