ちょっとした小ネタ。

弊社は主にRubyかPHPでプログラムを書くことが多い会社なので、今回はGo言語とHaskellについて
書いてみようかと思います。

Haskell製の自作ツールをGo言語で書き直していたのですが、あるディレクトリ配下のファイル一覧を
取得する処理を簡単に記述できたので、ちょっと比較をしてみようかと思います。

Go言語（MacOSX go1.3 darwin/amd64）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

package main
import (
	"fmt"
	"os"
	"path/filepath"
)
 
func main() {
	var result []string = make([]string, 0) // グローバルはいや！
	walk := func (p string, info os.FileInfo, _ error) error {
		if info.IsDir() {
			result = append(result, "Directory: " + p)
		} else {
			result = append(result, "File: " + p)
		}
		return nil
	}
	filepath.Walk(".", walk)
	fmt.Println(result)
}

Haskell（MacOSX ghc version 7.6.3）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

module Main where
 
import Control.Monad.Writer
import Control.Monad.State
import System.FilePath
import System.Directory
 
 
main :: IO ()
main = go "." >>= print
    where
        go p = execWriterT $ runStateT walk [p] -- go :: FilePath -> IO [FilePath]
        walk = do -- walk :: StateT [FilePath] (WriterT [FilePath] IO) ()
            p <- get
            case p of
                (x:xs) -> do
                    d <- lift . lift $ doesDirectoryExist x
                    if d then do
                        files <- lift . lift $ getDirectoryContents x
                        put $ xs ++ [x </> f | f <- files, f /= "." && f /= ".." ]
                        tell ["Directory: " ++ x]
                        else do
                            put xs
                            tell ["File: " ++ x]
                    walk
                _  -> return ()

たぶん、似たようなことをしているかと思います。

まとめ

今日はGo言語が1.3がリリースされました。もう、心がぴょんぴょんしてきます。

また、もっと簡単にかけるぜ！という方、もしくは、PHPやRubyなどに興味があり、
Fusicで一緒に働いてみたいという方はこちらの
フォームからご応募くださいませ。

それでは。

先日、YCAMに池田亮司 “supersymmetry”の作品とライブパフォーマンスを観に行ってきました。圧巻でした。お近くの方は是非。

Fusic勉強会、10回開催

Fusic勉強会を社外に公開することにしてから無事10回を開催することができました。

もともとが社内勉強会だったものを「より内容をクォリティを高く」という視点から社外への公開へ踏み切りましたが、一定の効果は得られたのではないかと思います。少なくとも社内では「以前の勉強会よりも質が高くなった」という評価でした。

やはり「外部の人に見られる」という点は、刺激が得られますね。

一方で「もう少ししっかり告知をして、いろいろな人に見てもらえるようにしたほうが良かった」というのは反省点です。

Fusic勉強会のこれからと期待すること

無事10回を開催したわけですが、このままだらだらと開催していてもしょうがありません。どうせ開催するなら「もっと、より、効果があったほうがいい」ですからね。

最近は、各プロジェクトにおける技術要素が異なってきています。また、社外の勉強会に参加する人が増えてきました。
そうなると、「いまのままの方法での」「定期開催な」Fusic勉強会だとちょっとお荷物になりかねません(効果と、スケジュール的に)。

というわけで「定期的な情報交換」という要素は他のやり方で検討するとして、社外に公開するFusic勉強会は不定期開催とすることにしました。

社内では「もったいない」という声もありましたが、そういった人たちからまた新しい勉強会が出てきそうなので、逆に期待です。

個人的にもFukuoka.rbにずっと参加させてもらっていて、「ストイックにもくもくやるの、いいなあ」などと思っているところです。

というわけで

別にFusic社員が外に出なくなるわけではなく、むしろ出ていくことが多くなるかと思いますので、
今後ともFusicをよろしくお願いいたします。

さて、今回のFusic勉強会ではちょっと細かい話をしました。

環境管理の必要性

Rebuildでも「前時代的」で有名なEmacsですが、自分はそのEmacsを利用しています。

さらにターミナル越しに使うことを徹底しています。
その理由も今ではレガシーなのですが、もともとは「会社の完全体開発環境をVPNごしでいつでも使えるようにするため」だったりします。開発環境をもう一度構築する大変さを実感していたからでしょうね。

ところが今では「不十分ながら」もEmacsにもパッケージ機構がつきましたし、MacならばBrewfileまで登場しています。

これはいける！ということでhomesickにまで手を出し始めました。

github.com/technicalpickles/homesick

github.com/k1LoW/dotfiles

やってみた結果

Vagrant上の開発環境にもコマンド1つで自分の最新開発環境が作れるのはとてもいいです。自分のVagrantの使い方は多少寿命が長いので、いい感じです。

あと、自作elのモダン化が辛いです(鋭意MELPAに登録中)。

まとめ

Rebuild聞いた？

たぶん誰にも響きませんが、ここ最近の心の叫びを
「Quarz Composer Pluginを64bitでBuildしたらVDMXでうごかねーじゃねえか！！」

さて、先週のFusic勉強会でPandocについて発表をしましたので共有します。

また、気軽に試してみたい人用にCentOS用のVagrantfileも作成しました。

github.com/k1LoW/pandoc-vagrant-ansible

(※TeXLiveのインストールに、あまりに時間がかかるためか必ず途中で失敗します。しかし、エラーメッセージをよくみて途中からTeXLiveのインストールを再開してみてください。その後再度vagrant provisionでその後の再開が可能です)

Pandocとは

「a universal document converter」の通りマルチなドキュメント変換ツールです。

いろいろあって、MarkdownからPDFとかWordとか生成できたらなーと思い、たどり着きました。

使ってみた感想

• Markdown + Cacooが気持ち良いです。ドキュメントも図もしっかりバージョン管理
• Wordが意外に綺麗にでてくるのに驚いています。しかし、スタイルの指定などがしっかりと動きませんでした。
• PDFの方はLuaLaTeXを介して出力ができました。
• さらにPandocのMarkdownは拡張されていて、中にTeXを書くことができます。documentclassの指定もできます。ということはLaTeXなので、いくらでも体裁を整えることができそうです。

というわけで

大学以来、久しぶりにLaTeXを触り始めました。

Pandoc、なかなか良いです。

少し遅くなりましたが、2月7日に「Fusicの中途採用についてみんなで考えてみよう」というお題目で、社内で呑みながら話しましたので、共有したいと思います。

Fusic Internal Drink Upとは?

「呑みながら社内メンバーで社内について話そうぜ」という言葉をアルファベットを使って格好良くしただけです。

別の言い方で言うと「お題を決めて社内で呑む」です。

今回が初めての開催で、いろいろ課題もありましたが、概ね良かったと思います。

まずはピザとビールで乾杯

今回参加してくれたのは社長を含めた7人でした。ちなみに参加は任意です。

「社長がいたら言いたいことが言えないのではないか？」という考え方もあるかもしれませんが、Fusicの場合はあまり当てはまりません。むしろ参加してもらうことで「今までの方法」についても話してもらえると思えたので非常に助かりました(社長も任意参加です)(一方で社長に限らず「声が大きい人が多い」というのは課題でもあります)。

自分の「まずは気楽に呑んで話してもらいたい」という考えから、普通の居酒屋のように小さくテーブルを囲んで座ってもらいました。そして、そのテーブルを埋めるように模造紙を敷き、その上にピザと飲み物を置きました。

そしてそれぞれにビールとペンを渡して、まずは乾杯から。

ピザとビールの割合のベストプラクティス

ピザとビールの割合を決めるのには beer-party.candycane.jp/ を利用しました。このシステムには、先人による素晴らしい経験則からくる計算式が組み込まれているので、そのまま信用しました。

(Twitter上ではお騒がせしました)

呑みながら書くルール

今回は「中途採用について」いくつか聞きたいことリストを作成し、
それを参加者に渡して

• 話題は中途採用に絞る
• しゃべりながらその内容をテーブルの模造紙にペンで書く

というルールだけ伝えて、後は主催者の自分もそのまま参加してしゃべりました。
ルールはこれだけです。

結局19時から初めて22時くらいまでしゃべっていたのではないでしょうか？
話題が真面目だと熱くなりがちですね。

Fusicの中途採用の流れ

Fusicの中途採用の方法は、まずは転職サイトやエージェントを介して募集するところまでは普通だと思います。

ただ、「まず面談するのが社長」というルールがあります。
(なんとなく「一般的な採用の流れ」とは違う気がしているのですが、なにせ自分が「Fusic新卒採用」なのでよくわかっていません。)

そのあと「社員(主に技術者)による面談」が「複数人続けて」あります。

面談をする社員は、別に「マネージャ」とか「この人」とか決まっているわけではありません。「最初に面談した」社長が特性を見て決めているイメージです(ときどき自分たちに「誰が面談したほうがいいだろう」と聞くこともあります)。

具体的に挙げると「インフラに強そうな人なら @debility」とかでしょうか？(あくまで例です)
今までのバックボーンやこれから担って欲しいと思っている領域から決まることもあります。

全ての面談終了後、面談をした人全員で話をして、判断をしていきます。

面談を複数人する理由

10分程度(話が盛り上がれば30分以上)の面談を、連続して受ける側にとってはとても大変です。

ただ、Fusicでは「一緒に働きたいかどうか」ということは「お互いにとって」とても重要なので、社員にも多く会ってもらっています。

社長がいつも言うのは「面談中は自分たちも見られているのだから」ということです。Fusicの社員は「嘘偽りで着飾る」ことは性格的にできませんが、できるかぎり良いところを(もしかしたら悪いところも)精一杯伝えようとはしていると思います。

また「技術的視点」でも「その人の良い部分を見逃さないように」複数人がいいと思っています。Fusicには全てに長けているスーパープログラマはいないですから。

中途採用について語ってみた・質問してみた

今回はじめて「中途採用について」みんなで話をしましたが、いろいろな側面から知ることができました。

聞かないとわからない中途採用の実状

例えば、以下のようなことは特に全員で共有する機会はなかったかと思います。

• 1人採用するのにだいたいどれくらいの費用がかかるのか
• 今までどのような募集方法をとったのか
• 今までの応募数
• 今までの面談数

知ることで中途採用について少し具体的にイメージすることができました(会社がどれくらい本気なのかなど)。

当然回答者は社長です。こういう時に社長が参加していると気軽です。

でも、基本的に「聞かれれば答えられる」ことだったんですね。(Fusic社員は中途採用に限らずいろいろ聞いてみましょう。)

Drink Up中の主な論点

Drink Up中の主な論点を少しだけ箇条書きで共有します。

• Fusicは圧倒的に知名度が足りない。直近でできるものでどうにか施策を実施する必要がある
• 技術Blogのテコ入れ？
• 社内チャットチャンネルの速報性をBlogに書いてもいいのでは(セキュリティ情報など)
• もっと気軽に
• 会社が目立つべき？個人が目立つべき？両方？現実的なのは？
• 社長面談の前に技術者面談を入れて「社長ではわからない良い技術者」を見つけるべきでは？(社長、技術的に信じられてない。。。)
• Fusicホームーページに中途採用専用ページがなく本気度が伝わらない
• 福岡においては、GitHub採用やQiita採用は果たして有効なのかわからない(Fusicには◯次面接というものがないので面接スキップというわけにはいかない)
• 面談をした社員と話して入社を決意した人がいる

その他ここでは書けないことや、奇抜すぎるアイデアなど、いろいろ出ました。

みんな、いろいろ考えています。

開催してみた感想

自分一人ではとても考えつかないポイントやアイデアを得ることができました。中途採用難しいです。
また、開催してみたいと思います(まずはもっと動かないと。。)
参加者にとっても「未来に一緒に働く仲間について」考えるいい機会だったと思います。

Fusicではエンジニアを募集しています。
また、「こうだったら入社したくなるのに」というご意見、アイデアも募集しています。

どうぞ！よろしくお願いいたします！

10周年記念パーティーのときもそうでしたが、弊社ではなぜか行事ごとに力をいれていて、IT会社らしくITを使って何かやるというのが「仕来り」になってきています笑

ということで今回も
・みんなが知っているゲーム
・ルールが単純
・チーム対抗で楽しめる
を前提に幹事チームで考えた結果、アタッ○25「っぽい」ゲームをやってみましたw

使用した技術

Pusher(pusher.com): 早押しボタンなどのリアルタイム通信のため
Sinatra: Pusherのサーバ側、Publishや認証のため
MongoDB: パネルの状態保持のため
Grunt: CoffeescriptとかLessのコンパイル自動化のため

今回はPusherにリアルタイム通信周りを「おまかせ」したおかげで、ほとんどサーバサイドが必要なく、Html・CSS・Javascriptのクライアントサイドアプリになったかなという感じ。
なのでRubyは最低限必要部分だけで、メインはSinatraのpublicディレクトリにGruntでクライアントサイド開発をしやすい環境整えて、開発していきました。

実際Pusherのおかげでリアルタイム通信部分はほんとに少ないコードで書けて
・Sinatra側でPublish用のメソッドを用意
・JS側でチャンネル・イベントのバインドとAjaxでのデータPOST
だけで、簡単にリアルタイム通信を行うことができました！

例えば、早押しボタンを例にすると

Sinatra側のPublishメソッド

1
2
3
4
5
6

# server.rb
post '/pusher/publish' do
  Pusher.trigger('channel-name', params[:event],
    params[:contents]
  )
end

Ajaxで早押ししたチーム色のPOST

1
2
3
4
5
6
7
8
9
10
11

# buzzer.coffee
$('#buzzer').on 'click', 'a', ()->
  $(@).attr('href', "##{color}")
 
  $.ajax
    type: 'POST'
    url: '/pusher/publish'
    data:
      event: 'attack:buzzer'
      contents:
        color: color

早押ししたチーム色の音をならす・一番早かったチーム以外受け付けない排他制御・回答者を点滅

1
2
3
4
5
6
7
8

# panel.coffee
channel.bind 'attack:buzzer', (data)->
  return if fastest
  fastest = data.color
 
  playPlay('panel-' + fastest) #早押ししたチーム色の音をplay
 
  flashOn(fastest) # 回答者点滅

のような感じで、簡単にリアルタイム通信を行えます。

また幹事チームの役割分担もけっこううまくできて

上司W: 当日の進行・景品の準備・音源の獲得。
上司O: パネル画面の実装・映像問題作成。
僕: サーバ側・早押しボタン・ポイント画面の実装。

といった感じで役割分担し、全体の構成や問題についてはみんなで話し合って進めていきました。

あと今回最後の映像問題の答えが「黒田官兵衛」だったので、昼休みにわざわざ福岡城に撮影しにいったり、先輩たちに「無理やり」筑紫もち早食いさせられたりと、良い?思い出があったりしますw

当日もよりリアルな雰囲気を再現するため、幹事はコスプレしたのですが、なぜか白髪のおじさんじゃなくて「バーコードハゲ」だったり、アナウンサーではなく「女子高生」だったり、なぜかなぜか「お地蔵さん」がいたりとなかなか面白かったです笑

感想やまとめ

・当日は思った以上にみんなが真剣にクイズとか考えてくれたし、盛り上がってよかった。
・無駄にアタッ○25に詳しくなった。例えばパネルがめくれる際の音は赤・白・青・緑、全ての色で違うとかw
・幹事チームのメンバーは普段案件とかであまり関わりがなかったので、短い期間ですががっつり絡めてよかった。
・普段業務で使ったことがなかった技術、今回でいえばPusherやGruntなど使えて勉強になった。

以上、次回の行事ごとにも期待です！

本日は自分がエンジニア採用担当になったお話をしたいと思います。

Fusicは本当にエンジニアを採用したい

さて、弊社Fusicもありがたいことに、慢性的にエンジニアが不足しており、
「エンジニアを採用したい」と常々考えています。

特に昨年後半から体制を大きく変えている段階で、今年から大きく前進したいと思っています。

そのためには、今の仲間同士のレベルアップも必要ですが、さらに一緒に働ける心強い仲間を増やすことも必要だと考えています。

Fusicは本当に「エンジニアを採用したい」と思っています。

どういうエンジニア採用の方法がいいのか？

とはいえ、今までの「普通の」エンジニア採用だと、なんとなく受け身な気がしています。

一方ですごいスタープログラマが在籍しているわけでもないので、ブラックホール的にエンジニア採用が成功するわけでもありません。

エンジニア採用にはエンジニアが関わった方がいいらしい

最近、Gihyo.jpで、連載していた「なぜ，エンジニアの採用は難しいのか？」が最終回を迎えましたね。
自分はエンジニアですが、「エンジニアの採用って難しいよなあ」と、とても興味深く読ませてもらっていました。

連載の中で、「エンジニアをエンジニア採用に積極的に関わらせるべき」という話がありましたが、「現場感が重要」なんだと感じました。

たしかにFusicのエンジニア面接では、多くのエンジニアが面談に関わります(どういうものかはいつか書いてみたいと思います)。

ということで、Fusicではエンジニアがエンジニア採用担当になってみました

私はエンジニアです。お客様とのやり取りもしますが、エンジニアです。

GitHubのContributionsを見てもらえばわかるかと思いますが、ちゃんと活動しています。

で僭越ながら、エンジニアとしてエンジニア採用担当になりました。

多分多くのエンジニア中心の会社でもやっていることかもしれませんが、Fusicとしては初めてのことじゃないかと思います。

だけど「どういうエンジニア採用の方法がいいのか？」はわかっていない

「困った時は聞けばいい」と思っているので、来週2月7日に社内のみんなを集めていろいろ聞こうと思っています。

Fusicにも中途採用の人も新卒の人もいるので、「どうしてFusicを選ぼうと思ったのか」ということなどを聞いてみたりして、良いアイデアを思いつくきっかけにしようと思います。

ちなみに、自分はFusic最初の新卒です。

エンジニアブログですが、エンジニア採用についても書いていこうと思います。

「どういうエンジニア採用の方法がいいのか？」もですが、「どうやったらFusicに興味を持ってもらえるのか？」「どうやったらFusicのエジンバラ像を知ってもらえるのか？」なども大事だと思っています。

多分その答えはエンジニア自身(社内外問わず)が知っていると思うので、エンジニアが見ているこの技術ブログに間借りして書いていこうと思います。

Fusicのエンジニア採用について、面白アイデアや、「Fusicのここが知りたい」といった質問まで、いろいろな声をもらいたいと思っています( @k1LoW や oyama@fusic.co.jp など、お気軽に！)。

隔週でFusic勉強会も開催しているので、その時につかまえてもらっても構いません。

「こんなエンジニア採用担当がいてもいいじゃないか」と、信じつつがんばっていきたいと思います。

また進展があったら書きます。

あ、技術についても書きます。

おまけ追記

社内エンジニアに、「エンジニアエンジニア言いすぎ、エジンバラが混じっていてもわからない」と言われたので、混ぜてみました。エジンバラをエンジニアに置換して読んでいただければと思います。

久しぶりにEmacsの設定を見直そうとしたら、自分のあまりのelisp脳の衰退に驚愕しました。

さて、明日の1月30日はFusic 勉強会 #6が開催されます。

Fusic勉強会 #6

自分は「実践Vagrantを利用したサーバ移行 (VagrantのMultiVM設定からさくらVPSの複数台構成まで)」というタイトルで発表をします。

内容としては

いままで複数台構成の専用サーバで数年運用していたシステムを、複数台構成のさくらVPSに移行するプロジェクトが発生。移行前にまずはVagrantのMulti-Machine機能を使ってローカル上で複数台環境を構築、サーバの設定を全てAnsibleに移行し、ローカルでテスト。最終的にそのAnsible設定を『そのまま』実行して複数台構成のさくらVPSへの移行を実現。

という内容なのですが、実は上の話の前に「PackerでVagrant用boxを作る」という作業がありました。

明日の勉強会ではその話は飛ばしますので、ここで紹介したいと思います。

なお、今回の内容はまさに「OSXでpackerでCentOS6.4のVirtualBox VMを作成する」を参考に作業したものですので、是非こちらもご覧ください。

Packerとは何？

VMWareやVirtualBoxを開発で利用するようになってから結構立つかと思いますが、最近はVagrantとかPackerとかDockerとかいろいろ便利と言われるツールがでてきて、混乱しますね(自分はしました)。

で、今回利用するPackerとは何で、どこが便利なのか、良く分からない人もいるかと思います。

Packerの正確な説明は、皆さんがググった結果や他のサイトにお任せしますが、「個人的で局所的」なPackerの利便性の説明をしてみます。

VirtualBoxを便利に使うためのVagrantを便利に使うためのPacker

既に「VirtualBox」と絞ってしまっていますが、「個人的で局所的」なのでご勘弁を。

VirtualBoxなどの仮想環境を使ったことがある人は多いと思いますが、そのVMの生成のためには「(isoなどを利用した)OSのインストール」が必要で、毎回毎回「インストール時間分」時間がかかっていました。

それをVirtualBoxの「仮想イメージのインポート/エクスポート機能」をつかって、時間の短縮した人もいるかと思いますが、その部分を担っているのがVagrantです。

Vagrantは「box」という仮想イメージを管理し、必要に応じてその仮想イメージからVMを簡単にVirtualBoxに生成できるわけです。
(さらにVMwareでも！的な話は省略します)

じゃあ、その「box」はどこからもってくるの？となるわけですが、まず2つが考えられます。

• ネット上に公開されているboxを利用
• VirtualBox内で動いているVMから生成

「ネットで公開されているboxは何がインストールされているかわからないからちょっと。。。」という人は必然的に「VirtualBox内で動いているVMから生成」となるわけですが、じゃあ、その「VirtualBox内で動いているVM」はどうやって作るの？また自分でisoから作るの？面倒！となるわけです。

(Vが頭文字の単語が頻出して、だんだん禅問答みたいになってきましたが、もう少しだけがんばってください)

その最後の面倒な部分を担うのがPackerです(と、思っています)。

Packerは、例えば「VirtualBoxのVMをisoから作成し、そこからVagrant用boxを作る」という部分を、「JSONで記述された設定ファイル(といくつかのスクリプト)」を用意するだけで自動化してくれるのです。

個人的なPackerのポイントは「JSONで記述された設定ファイル(といくつかのスクリプト)」という部分です。

JSONやスクリプトはバイナリと違い、自分で読めるので、「ネットで公開されているもの」を使いやすいのです。

ChefのコミュニティCookbookのように夢が広がりますね(Ansible使いですが)。

Packerでboxを作ってみる

VirtualBoxは既にインストールしてある前提です。Packerのインストールは「INSTALL PACKER」を参考にしてください。

今回はCentOS6.5のVirtualBox用boxを作ります。Packerはv0.5.1を前提にしています。

Packer用JSONファイルを探す

自分でpacker.jsonを記述するのは面倒なので、インターネット上から設定を探します。
github.com/hnakamur/my-packer-template-files がとても素晴らしいので、こちらを使います。

$ git clone github.com/hnakamur/my-packer-template-files

設定の中身を確認する

$ cd my-packer-template-files/centos6.5

centos6.5/template.json を確認するとprovisionersでいくつかスクリプトを実行しているようなので、それぞれのスクリプトで何が実行されているか確認します。

例えばcentos6.5/scripts/vagrant.sh のスクリプトはVagrantで使う前提の設定をしてくれているなど、いろいろな設定が実行されています。感謝しかありません。

Packerを実行する

$ packer build -only=virtualbox-iso template.json

はい。終わりです。packer_virtualbox-iso_virtualbox.boxというboxが生成されているので、こちらのVagrantのboxとして追加するだけです。

$ vagrant box add centos6.5 packer_virtualbox-iso_virtualbox.box

最後に

ここまで見ていただいた方はおわかりかと思いますが、
Qiitaの参考URLも、使ったPacker用JSONもHiroaki Nakamuraさんが公開されているものです。
素晴らしい情報を提供していただいたNakamuraさんにこの場を借りて御礼を言いたいと思います。
どうもありがとうございます！

というわけで、続きはFusic勉強会 #6で！

新年ですね。まあそんな気分は既にふっとんでいますが。

さて、Fusic勉強会 #5が1月16日(木)に開催します。

Fusic勉強会 #5

皆さんふるって参加してください。

「今さら」をもう一度紹介する

Fusic勉強会はジャンルがバラバラです。さらに発表者に「今さら？？」というような技術情報をあえて発表してもらったりしています。

というのも、先輩には「今さら」「当然」でも、新人や慣れていない人には「初めて」ということがあるからです。

主な原因の1つとしてドキュメントの不足がありますね。

ドキュメントがあれば、後々共有できたり学ぶ手助けができます。
ドキュメントがないと、「そのとき」に共有した人だけが使えるツールになってしまいます。

例えば、これとか、これとか、これとか、READMEがないとか最悪ですね。。。。ですね。。。。です。。。

そうでなくても、「その当時は暗黙の了解」なトレンドな技術やツールがあったと思います。なかなかドキュメントに残らないですよね。。

今回の発表内容にもある「TestFlightでスマホアプリのデバッグをラクにする」も、もともとは自分から発表者に依頼しました。
本人には新規性がなくても、知らない人にはとても有用だと思います。

このように、Fusic勉強会では、ときどき「今さら」な発表があったりします。

もし発表内容に「聞いたことがあるけど学ばなかった技術」などがありましたら、いい機会ですので聞きに来てください。「今さら」ですからレアですよ？

前回のブログが半年前の「ソフトウェアテストのワークショップ【WACATE】で賞をいただきました！」だったのですが、

今回も同じタイトルで記事が書くことができます！

１２月１４日～１５日にWACATE(Workshop for Accelerating CApable Testing Engineers)という若手エンジニア向けワークショップに行ってまいりました。

（前回フォローしていませんが、ワカテと読みますが年齢制限はないのです！）

参加したワケ

前回から半年後の今回参加したわけは、以下になります

• WACATE参戦後、急加速することになった自分自身の成長の成果を確かめるため
• この半年でさらに関係が濃くなった仲間たちとワークショップを通じてあらためてモチベーションを高めるため
• 夏とは違うセッションを楽しむため

ワークショップについて

詳しくは後述しますが、別のサイトで詳しく書くことになりそうです。（プログラムはWACATEサイトを見てみてください。）
ですので、全体的な感想を。。

夏のセッションは絞られたセッションを深くチームで考察し、発表まで行う形式。冬は多くのセッションを広く受ける形式となっており、本当に色々なセッションを受けました。

とくに「テスト」の枠に縛られず、品質の話であったり、論文寄稿の勧め、相手に勧める戦術など、テストエンジニア以外の方が聞いても役に立ちそうな話題があふれていました。
また、セッション担当を実行委員がするのですが、どなたのプレゼンも本当に素晴らしく、価値があるワークショップだと思います。
参加者たちもテスト界隈で有名な方々が全国から来ていて、各テーブルでの話も貴重でした（私のグループも初めてお会いする有名人がいて、色々お話聞けて面白かったです）

BPP賞とは

※前回の記事より

WACATEでは、参加登録の際に参加表明として「ポジションペーパー」というものを提出するのですが、最終的に3つの賞を決めます。
3つの賞が一貫して「今後期待できそう、勢いを感じる」というテーマで決定します。

• 実行委員が決めるMost Accelerationg Paper賞
• 招待講演者が決めるBiased Favorite Paper賞
• 参加者の投票で決めるBest Position Paper賞

そして、僭越ながら　私が

Best Position Paper賞
をいただきました！！

受賞の理由は、ポジペのデザインや作成時間の功労を評してくれた方や

ポジペの内容が「加速している」と感じてくれた方に評価していただいたようです。

選んでくださったみなさま、ありがとうございます。

今回のBPP賞の副賞として、

• 夏に私が運営しているグループも寄稿した同人誌「Software Testing “ManiaX”-vol.8-」
• 同人誌「メトリクス公団」
• gihyo.jpへの寄稿
• 次回WACATE無料ご招待（ただし、BPPセッションの登壇）

をいただきました！

詳しいWACATEの内容は来年寄稿すると思いますので、お楽しみに♪

前回のブログの最後に「BPP賞が欲しい！」という願望を書いていたことをすっかり忘れていたのですが（ビッグマウスだった・・・）、それでも無事願望が達成できてよかったです。

次の半年は寄稿や、セッションのためのプレゼン準備にもがんばりたいと思います。