Tech Talks 第3回 開催レポート

開発部の渡邊 (@nownabe)です。社内技術勉強会Tech Talksも3回目の開催となりました。

開発環境

by @ws-yuta-saito

開発環境の紹介でした。開発環境と聞いて「これ宗教戦争起きるやつじゃないですか？」「いや大丈夫です」というやりとりがありましたが、案の定戦争勃発していました。

紹介されたのはAlacrittyというRust製のターミナルエミュレータと、SpacemacsというEmacsとVimの良いとこ取りをしたEmacsのディストリビューションでした。

大切なことはすべて Creon が教えてくれた

by @fista

Creon というサービスの振り返りでした。どういう時系列でどういう理由で何があったのか、どうすればよかったのか、というのが丁寧に振り返りされていてとても参考になる発表でした。

My Favorite Youtuber

by @mmyoji

最近お気に入りのYoutuberの紹介でした。 紹介されたのはしをたんともこうでした。

HOT PLUG

by @guregu

自身が作成したGo製ゲームHOT PLUGのデモでした。Kawaii Solutionsというサークルでコミケにも出展していたゲームです。 デバッグモードで起動して、当たり判定の説明や敵のAIの話も交えつつゲームをプレイして盛り上がっていました。

「Tech Talks」第2回 開催レポート

こんにちは。andoです。 10/12に第2回「Tech Talks」が開催されたので、その様子をお伝えします。

Tech Talksとは？

Tech Talksは、 エンジニアとかが雑にLTする会 をコンセプトに始まったWondershakeの社内技術勉強会です。 前回の開催から約1ヶ月、2回目の開催となりました。

発表内容

今回は飛び込み含め5つのLTがありました。それぞれ軽く紹介します。

1. イカのある生活-2

資料｜イカのある生活-2 by @mmyoji

前回同様、任天堂のスプラトゥーン2というゲームについてのLTです。 @mmyojiさんの現ステータスや、新しく見つけたオススメYoutuberの紹介などがありました。次回はデモをやってくれるそうです。Sランカーはどう動くのか？！楽しみです。

2. milcocoを支えるプロセスとアーキテクチャ

by @k0uki

milcoco(ミルココ)のサービス説明から始まり、リリースまでの軌跡や、現在何をしているのか、これからどうしていくかについての発表でした。Wondershakeは現在LOCARIとmilcoco(ミルココ)ふたつのサービスを運営していますが、社内のエンジニアはほぼLOCARI事業に所属しているので、milcoco事業への理解が深まる発表でした。

3. Learn X Programming Language

参考サイト｜ 1. learnxinyminutes.com 2. hyperpolyglot.org 3. rosettacode.org 4. exercism.io 5. howistart.org by @ericd

エンジニアが新しい言語を学ぶ時に役立つサイトの紹介でした。似ている言語の比較について書かれたサイトや、100以上の言語について紹介しているサイトなど、目的別に使い分けることで学習が捗りそう！

4. ゲームとか個人開発についてのさむしんぐ

資料｜ゲームとか個人開発についてのさむしんぐ by @anzfactory

個人でいくつもアプリをリリースしている@anzfactoryさん。今回はその中から「村人Aの奮闘〜ふたりで地下からの脱出（iOS版、Android版）」についての発表です。DL数や売上金など、生々しい話もあり。個人的には、個人開発のモチベーション(の本音) 業務プロの疲れを趣味プロで解消している に「なるほど」と思いました。

5. Selling Go Game at Comiket

資料｜Selling a Go Game at Comiket by @guregu

時間が余ったので、飛び込みで！@guregu さんのGolangで開発したゲームをコミケに出展したときの発表でした。コミケを好きな理由（うみねこの鳴く頃にがきっかけらしい）から、コミケで出展するときの心得、ゲームを実装する方法についての発表でした。Golangのゲーム開発ライブラリの紹介やゲーム開発で使われるInterfaceの紹介があり、ゲーム好きエンジニアにはとても興味深い内容だったようです。

おわりに

今回はピザとお酒を持ち込み、飲食をしながらのラフな会でした。 また、その場で次回のトーク者を募ったところ4名の方が立候補してくれたので、次回も開催します！

社内技術勉強会を開催しました

こんにちは！開発部の渡邊 (@nownabe)です。 今週、社内で技術勉強会を開催したのでその様子をお伝えします。

なぜ社内勉強会？

今回の社内勉強会は社内の全エンジニアと対象として、ゆるいLT大会形式で開催しました。 目的としては大きく次の2つがあります。

• エンジニアのモチベーション向上
• 社内の技術力向上

今回の社内勉強会では特にモチベーション向上に焦点をあてています。 モチベーションが向上すれば技術力につながる可能性も高いからです。

社内勉強会でそれが実現できるかというところですが、次のような要素から可能だと考えています。

• 発表を聞く
  • 面白い話を聞いて楽しむ
  • 他の人の発表をきいて自分も何かしたいと感じる
• 発表する
  • 発表駆動開発する
  • 発表で仕事のストレスや鬱憤を晴らす
• コミュニケーション
  • 普段関わりがないエンジニア同士でコミュニケーションする
  • 技術的な会話でテンションが上がる
• などなど

技術力向上という点に関しては直接参考になるLTがあったり、上がったモチベーションで技術力が身につけばよし、という程度の目的としています。

今回は初回のお試しということで開催しましたが、継続的に開催していきたいと考えています。

やり方

勉強会に参加することや発表することのハードルをできるだけ下げたかったので、次のようなLT大会を設計しました。

• 参加者
  • 参加自由
  • 出社する人が多い木曜日に開催
  • お菓子や飲み物を用意
• 発表者
  • 発表テーマはなんでもあり
  • 発表時間は5〜20分程度
  • 初回の発表者にはこちらから依頼

参加自由とは言え参加者がまったく集まらないとモチベーションは逆に下がってしまうため、次のような方法で参加者を集めました。

• Googleカレンダーで招待
• Slackのエンジニア雑談チャンネルで呼びかけ
• ミーティングなどで呼びかけ
• マネージャーに1 on 1で呼びかけてもらう

また、発表者へのフィードバックのためのアンケートを用意しました。 継続するためには発表してくれる人が必要なので、軽いインセンティブになればいいと考えています。 質問項目はこのようになっています。

アンケート自体も負担になるのは避けたかったので回答義務は無し、必須項目なしとしています。 今回はアンケートを導入しましたが、今後は様子をみつつ改善または廃止する予定です。

発表内容

今回は4つのLTがありました。それぞれ軽く紹介します。

これまで作ってきたものについて by @takumiumiu

開発部部長による今までの会社で作ってきたものや、大学・大学院での研究で作ってきたものの紹介です。 特に研究に関する話は普段見慣れないものばかりで興味深く楽しめました。

イカのある生活 by @mmyoji

イカのある生活 資料

任天堂のスプラトゥーン2というゲームの紹介です。 スプラトゥーン2で勝つために参考になるYoutuberの紹介などがありました。 私もスプラトゥーン2はプレイしていますが全然勝てないので参考にしたいと思います。

Brainf*ckを実装しよう by @nownabe

Brainf*ckを実装しよう 資料

Brainf*ckという難解プログラミング言語を実装しようという発表をしました。

DynamoDB and Go (v2) by @guregu

DynamoDB and Go (v2) 資料

AWSのDynamoDBの自作Goクライアントの紹介です。 使い方の紹介がメインでしたが、このAPIはこのライブラリを参考にしているといった話もありとても楽しめました。

このライブラリはOSSで公開されているので、GoからDynamoDBを操作するときは是非使ってみてください。

github.com

おわりに

今回は初回ということもあり比較的多くのメンバーが参加してくれました。 Wondershakeでは普段リモートで働いているメンバーも多く、こういった直接コミュニケーションを取れる場も大切にしていきたいので勉強会は継続したいと考えています。

今回のアンケートでは発表のフィードバックに加えて、継続したいかどうかの質問もあったのですが概ね好評なので第2回も開催したいと思います。

LOCARI のコードレビューについて

この記事は Wondershake Advent Calendar 2016 22日目の記事です

Wondershake では基本的にほぼすべてのアプリでコードレビューが導入されています。（一部ソロ開発のものはレビューがない）

自分は基本的に LOCARI （のサーバーサイド）を開発してるので、それのワークフロー及びコードレビューで自分なりに気をつけていることを書きます

LOCARI のワークフロー

PivotalTracker, Github を使ってます 😄 （その他諸々ツールを使ってますが、基本的に見てるのはこの２つのみです）

1. PivotalTracker に issue 起票
2. 勝手に issue を取っていったり、アサインされたりする
3. issue に紐づく pull request （以下 p-r）を WIP: で作成
4. WIP: が取れたらレビュー担当によるレビュー
   • コードレビューと動作レビューがある
   • 機能追加の場合は後者必須
5. すべてのレビューが通れば、 p-r 作成者がマージ

PivotalTracker への起票をスキップしていきなり p-r 出すこともあります（主に自分）

地味に [WIP] ではなく WIP: としてあるのは嬉しさがあります。タイプ数が1文字分減ります。（どうでもいい）

コードレビューで自分が気をつけていること

ここからは自分語りです。イタい

70 ~ 80 %で approve 出す

物議を醸しそうですが、自分が 100 % だと思うものを求めてしまうと（おそらく）どっちでもいいことが混在したり、レビューで説明しきれない可能性があったりするので...

「本当はこう実装した方が」みたいな時は「自分であとで p-r 出せばいい」と思うので、実際にそうしてます

その機能開発が本当に正しいかどうかはユーザーに触ってもらって初めて評価できると思うので、なるべくリリース優先になるようにしています。

が、本来は100%でいけるに越したことないので難しいなぁと日々感じています 😇💔

WIP 段階でもなるべくチェック

「WIP だから！まだ見んといて！」となる方もいるかもしれませんが、お互いに余計な時間を使うのを避けるために、方向性に疑問を持ったりしたらコメントを残すようにしてます。

Review changes の Request changes は使わず、 Comment / Approve を使う

Github 限定の話です

機能としてはとてもいいんですが、思いっきり ❌ って出ちゃうのが心理的にアレで自分は避けてしまいます（すごいどうでもいい）

最近導入された Reviewers 機能 で右上に status が出るので別に Comment でもいいかなという気がしてます

最優先タスクをコードレビューにする

コードレビュー自体の話になってしまいますが、自分が以前働いていたところでそういう風に仕事してる方がいてかなり開発がしやすかったので、それをリスペクトして自分も真似してやってます

自分の開発は基本的に後回しにして、 p-r が作成されたらまず目を通します 😎🔎

他人の作業を止めるのが一番害だと思うし、出来てすぐのコードをチェックしてもらった方がモチベーション的にも良さそうなので。（自分は昨日書いたコードとか覚えてないので余計にきつい）

おわり

当たり前のことばかり書きましたが、以上になります。

明日は Go エンジニアの greg です。趣味でちょこちょこ Go を勉強しているので個人的に楽しみです 😍

Elixir / IEx の便利なコマンド

この記事は Wondershake Advent Calendar 2016 21日目の記事です。

僕もまだまだ Elixir のことを勉強中ですが、今回は僕が気に入ってる便利なコマンドお伝えしたいと思います！

IExで hを使う

基本的なコマンドかもしれませんがすごく便利だです。普通に iex で h のコマンド使うとElixirのstandard libraryのドキュメンテーションしか見れませんが、 iex -S mix から h のコマンド使えばプロジェクトをロードしているモジュールのドキュメンテーションを全部見れます。僕はphoenixのプロジェクトでよく h Ecto.Queryを見ます。

h(Module)

h(Module.function)

h(Module.function/arity)

IExで iを使う

もともとはRubyを書いているので、最初はRuby .inspect や .class を使えないので不便だと思っていましたがElixirのイントロスペクションはかなり良いです。

escriptでコマンドラインアプリケーションを簡単に作れる

1) 新しいプロジェクトを作る mix new cli_example

2) mix.exs で...

def project do
  [app: :cli_example,
   version: "0.1.0",
   elixir: "~> 1.3",
   build_embedded: Mix.env == :prod,
   start_permanent: Mix.env == :prod,
   escript: [main_module: CliExample], # <- これを入れるだけ
   deps: deps()]
end

3) lib/cli_example.exs の CliExample のモジュールで main functionを作る

defmodule CliExample do
  def main(args) do
    args |> IO.inspect
  end
end

4) mix escript.build でコンパイルする

5) ./cli_example [args] で使える！

まとめ

この記事でElixirの使いやすさ少しでもお伝えできていたら嬉しいです。

明日はまた @masa-myo です！楽しみです！

Rails のマイナーなコマンド

この記事は Wondershake Advent Calendar 2016 20日目の記事です。

ほんとは Elixir とかについて書きたかったんですが特にインプットがなかったため、しょーもないことを書きます。

tl;dr

The Rails Command Line — Ruby on Rails Guides に書いてることのうち、（個人的に）マイナー（そう）なやつについて書きます。

詳しくはリンク先を見てください

前提

5系以上はそれまで bin/rake だったコマンドもすべて bin/rails なので bin/rails として以下書いていきます

notes

bin/rails notes で FIXME, OPTIMIZE, TODO が付いているファイルをメッセージと一緒に表示してくれる

以下の拡張子に対応

• .builder
• .rb
• .rake
• .yml
• .yaml
• .ruby
• .css
• .js
• .erb

bin/rails notes:fixme で FIXME だけ表示

自分たちしか使ってないカスタムメッセージを表示したい場合は

bin/rails notes:custom ANNOTATION=BUG のようにして、 BUG と書いてあるファイルを探せる

TODO, FIXME あたりはよく(?)使うので使いたい

tmp

bin/rails tmp:cache:clear はよく使うと思いますが、cache とか pid 用の dir を作る tmp:create コマンドは知りませんでした

$ bin/rails tmp:create
mkdir -p tmp/sessions
mkdir -p tmp/sockets
mkdir -p tmp/pids
mkdir -p tmp/cache/assets/development
mkdir -p tmp/cache/assets/test
mkdir -p tmp/cache/assets/production

rails app を clone した後とかによく使うかも（覚えていれば）

time

time zone 一覧を表示するタスク。これほんとに必要？

$ bin/rails time:zones:all
# ...

* UTC +09:00 *
Osaka
Sapporo
Seoul
Tokyo
Yakutsk

* UTC +09:30 *
Adelaide
Darwin

* UTC +10:00 *
Brisbane
# ...

console

bin/rails c(onsole) はよく使うと思いますが、その中で毎回めんどくさいことしてたなーというものがあったのでメモ

$ bin/rails c
# app で代用できる
> Rails.application.routes.url_helpers.root_path
"/"
> app.root_path
"/"

# helper で helper のメソッドを呼べる
> helper.number_to_currency 1_999
"1,999円"

dbconsole

config/database.yml に定義してある mysql server へアクセスできる（console と同じでデフォルトが development）

直接 SQL 叩きたい時とかは便利

おわり

小ネタでした

明日は Eric です！

LOCARIのデザイン環境について

こんにちは、業務委託でお世話になっておりますデザイナーのこけしです。（本名は長谷部えりです） この記事は Wondershake Advent Calendar 2016 の16日目の記事です。

様々な記事が書かれていて賑やかでうれしいですね(^o^)！
前回の板部くんの記事はコチラです。とっても素晴らしい記事でした！！ engineering.wondershake.com

話すこと

• デザイン作業フロー
• フロー詳細と利用ツール

今回はLOCARIのデザイン環境についてです。

というのも以前よりデザイナーさんも増え、現在属人的な管理にならないよう、デザイン環境整備を意識して行っています。 そこでどのようにWondershakeデザイナーは働いて、その中でどのようなツールを利用して管理を行っているかおおまかにデザイン環境についてお話しようと思います。

デザイン作業フロー

ざっくりと書くとデザイン作業のフローは以下の通りです。
1. ディスカッション
2. 要件定義
3. アサイン
4. デザイン制作
5. クリエイティブチェック
6. エンジニアの共有

前提として、Wondershakeデザイナーの役割としては、デザイナーは要件定義された案件をもくもくとこなすというより開発メンバーと共にディスカッションをして組織として持っている課題をデザインで解決する役割も担当させていただいており、 UIUXデザイン〜広告グラフィックなど、広い領域で上流からデザイン制作を行うことができます。

フロー詳細と利用ツール

ディスカッション〜アサイン

週に１度、エンジニア・デザイナーの開発メンバーでディスカッションを行います。 こちらでデータから見えた課題や様々な窓口から受け取った課題を整理し、 優先度の高いものから各案件ごとに要件定義を行い、タスク化してアサインをしています。 タスクやアサインの管理はFlowを利用しています。

タスク管理ツール
Flow - Project and Task Management Software for Teams 案件ごとに決定したもの、議論したいことも書き込み、ログを追えるようにしています。
タスクとなりきれなかったアイデアなどもストックしておくことで、課題解決のヒントになることも！

デザイン制作〜クリエイティブチェック

デザイン制作では主にUI制作はSketch、グラフィック制作は（言うまでもないですが）Photoshopの２つを使用しています。
UI制作ツール
Sketch - Professional Digital Design for Mac

グラフィック制作
Adobe Photoshop CC
Adobe XDも話題となっていますが、以前からデザインチームではSketchを導入していたところもあり もう少し様子を見て、導入コストをかけてでも変更すべきと感じたら検討しようとしています。

デザイン完成後はデザイナー上長確認、エンジニア＋プロジェクトマネージャー確認を行い実装へ移していきます。

エンジニアへの共有

完成したデザインを共有するツールとしてはZeplinを利用しています。
デザイン指示書ツール
Zeplin

デザインの最新バージョン管理、デザイン指示書、素材書き出しなどをこちらで行います。

今まで作業したデザイナーのみが最新版を確認できる状態で、 デザインチーム内でも「どれが最新？」と混乱が起きがちでしたがこちらで一括管理することで認識違いが起きることが少なくなりました。

さいごに

大まかにLOCARIのデザイン開発フロー・ツール紹介をさせていただきました。
日々すごいスピードで新しいものが増えていっているので、ぜひオススメのフロー・ツール等々情報共有いただけるとうれしいです！ いろんなプロダクトのデザイン環境気になります。

お次はDIYレシピアプリのCreon Andoroidについて、たくみゅうみゅうことshirokuraさんが書いてくれます！楽しみです！
余談ですがshirokuraさんとわたしはWondershakeクラフトビール部に所属しています。
好きな方、ぜひ飲みに行きましょう〜！では〜！