メンバー同士でお互いの価値観を可視化するムービングモチベーターズを新チーム結成時に使ってみよう

id:radiocat です。今年度はビアバッシュ推進委員から一歩身を引いてアドバイザー役になりました。

このブログでも何度か紹介している ビアバッシュ ですが、このたび新しい運営メンバーが選抜されて、先日キックオフを行いました。同じ会社の社員とはいえ価値観は人によって違うため、ビアバッシュをどのように推進していきたいか、思い描くイメージはそれぞれ違っているものです。はじめはお互いに手探り状態で意見をすり合わせながらやりたいことをまとめていくことになりますが、そんな時に役に立つ価値観を可視化する手法が「ムービングモチベーターズ」です。

ムービングモチベーターズとは

チームのメンバー同士でお互いの価値観を共有するためのワークショップです。手法の成り立ちや考案者については後述します。

10種類のカード

モチベーションの源泉となるキーワードが書かれた10種類のカードがあります。このカードを自分が価値を感じる順番に並べ替えて共有します。

やってみよう

テーマの認識合わせ

まずは何に対しての価値観について考えるのか全員でしっかり認識合わせをします。今回は「開発部のビアバッシュを推進していくうえで価値が高いと感じるキーワード」としました。

実践タイム

5分～10分程度で時間を決めて並び替えます。あまり深く考えず直感的に並び替えましょう。

共有タイム

1人ずつ結果をチームに共有します。なぜそのキーワードを選んだのか理由も説明して価値観の理解を深めましょう。

今回はメンバーそれぞれが選んだトップ3を発表しました。このチームは「関係性」と「受容」を選んだメンバーが多いとか「名誉」や「権力」は誰も選ばなかったといったコミュニケーションを取って価値観を共有しました。

まとめ

ビアバッシュのような社内イベントの運営ではルールや手順が細かく決まっているわけではなく、むしろ集まったメンバーの個性や考え方に委ねられている面もあるので、このように手軽に価値観を共有できる手法はとても有効です。

また、私の所属する開発チームでは毎月1回全員でこれを行って前月からのメンバーの価値観の変化も追いかけています。「最近新しい技術に取り組んでいるので好奇心を選んだ人が増えた」とか、「難しい課題に取り組んでいるのでゴールの重要性を感じている」といった、チームの状況の変化に応じたメンバー同士の価値観の変化にも気づけます。

最後に、実践しするうえでのポイントを3つ紹介します。

気軽に並べる

結局どれも大事な言葉なのです。時間をかけずにその瞬間の価値観をさらけ出しましょう。もちろん隣の人のカードを見てはいけません。

言葉の捉え方も共有する

やってみると言葉の捉え方が人によって違うことにも気づきます。元々英語で作られたカードなので、「受容」や「熟達」など、日本語だと少しイメージしにくい言葉もあります。しかし気にする必要はありません。「自分はこう思ってこれを選んだ」という考えを共有することが大事です。どうしても気になる場合はみんながどういう意味で捉えているか聞いてみましょう。

楽しむ

お互いに価値観を共有しあうので、堅苦しい雰囲気だと発言しづらくなります。無言でカードを並べるのではなく、楽しくワイガヤしましょう。

参考：Management 3.0

ムービングモチベーターズはManagement 3.0のプラクティスの1つです。

management30.com

Management 3.0は 公式サイト で以下のように説明されています。

オランダ出身のヨーガン アペロ（Jurgen Appelo）の世界80ヶ国で展開している新しいイノベーションとリーダーシップそしてマネジメント運動です。

近年マネジメントの領域で注目されている自己組織化や心理的安全性などについても言及されており、アジャイル開発の現場でも手法が使われているようです。

ARKit + Unityでアプリ開発

こんにちはsts-250rrです。

今回も前回の記事に引き続きAR技術の紹介になります。

tech-blog.rakus.co.jp

前回は簡単にARを体験する。まででしたので今回はSoftware DesignのコラムにあったARアプリARKittenを作ってみました。

gihyo.jp

ちなみにGithubのリポジトリでサンプルを公開してくださっていますので、こちらでまず試してみるのも良いかもですね。

では、やっていきましょう。

猫、ARに立つ

前回はARの世界で平面を検出し、キューブを設置するところまででしたが、それではあまりに味気ないので猫を配置することにします。 ※AssetStoreからARKitをインポートする部分は割愛します。

UnityのAssetStoreでは、3Dのモデルデータを購入することもできます。
ここから猫のモデルを取得していきたいところですが、残念なことにARKittenで使用する猫のモデルは作成者の諸事情により、AssetStoreからダウンロードできなくなってしまいました。
現在は上記のGithubからモデルデータを取得してくるしかないようです。
Kittenディレクトリをプロジェクト名/Assets配下に格納しておきましょう。

単純に猫を平面に追加するだけでは、拡張現実らしくなりません。
それはなぜか、ズバリ影がないからです。

そこで今回作成するアプリではUnityARShadowsというサンプルを元に作成していきます。
このサンプルであれば平面を検出した部分に3Dモデルの影を落とすことができます。

UnityARShadowsにはCubeの代わりにHitPlayerが存在しています。
これをAssets/Kitten/Prefabs/KittenNPCに置き換えます。

これだけではiOSの画面をタップしても猫が平面に配置できないのでスクリプトを組み込んでいきます。

KittenNPCを選択しインスペクターウィンドウ（右側に表示されている設定窓）の設定を以下のようにします。

ここで一度ビルドして、画面をタップして見て猫を配置してみます。
猫に影がついていたり、アニメーションが定義されているので、まるで猫がそこにいるようです。

カメラを向かぬ猫

単純に猫を配置するだけでは、場所によってはそっぽを向かれてしまいます。
猫を配置した時にいつもこちら側（カメラ）を向いてくれるようにしつけスクリプトを追加していきます。
ここでは猫がカメラを向いてくれる時の処理の流れを解説します。

1. 猫位置の取得
   タップで配置した猫の位置を取得します。
   このままでは猫は初期の向きを向いてしまいます。
   3Dグラフィックスの世界では向き（回転）という情報はクオータニオンと呼ばれるもので保持されています。

2. カメラ位置の取得
   猫とカメラの位置（座標）を比較することで、猫がどの方向を向けば良いのかがわかるようになります。

3. カメラの方に向かせる 猫とカメラの位置の差から、猫がどれだけ回転すれば良いのかを計算します。
   この計算は3Dを扱うライブラリであれば、大抵3次元ベクトルを与えてやれば計算してくれる関数があります。
   ARKitであれば、QuaternionクラスのLookRotationクラスがその一つに該当します。
   ※スクリプトの内容はサンプルコードを眺めてみてください。

スクリプトが完成したら再びビルドしましょう。
そこには従順にこちらを向いている猫が佇んでいるはずです。

まとめ

今回は前回ご紹介したARKitのサンプルプログラムを作ってみました。 猫が配置され、それを眺めるまでしかできませんが、本来そこにいないはずの猫が画面を通して存在している感覚はまさしく拡張現実です。

次回も引き続きARKitネタをお送りしたいと思います。
お楽しみに、

実録ビルドできない事件簿

iPhoneのiOSをアップデートしたばかりにビルドできなくなってしまった・・・・

エラー内容を見てみると、 「iOS11.3のデバイスサポートファイルがない」ということだそうです。

みなさん結構起きてしまっているようで、解決策を調べてみたらすぐに出てきました。 今回は以下の記事を参考にさせていただきました。

iOSをアップデートしたために実機でビルドができない - Qiita

メールディーラーバージョン12.2をリリースしました！

ラクスのメールディーラーの開発を行っている@nerobluebrosです。
5月9日にメールディーラーのバージョン12.2をリリースしました。

今回はそのメールディーラーバージョン12.2とリリースについての紹介をします。

バージョン12.2では33の機能と修正をリリース

12.2では大小合わせて33の機能と修正をリリースすることが出来ました。
主な機能と修正は以下のとおりです。

1.添付ファイルセキュリティオプション機能
　・添付ファイルの拡張子と実際のファイルの内容をチェックします
　・ユーザ単位で添付ファイルのダウンロード可否をコントロールできます
　・期限付きのURLから添付ファイルのダウンロードができます
　・添付ファイルのみを対象に自動削除できます
2.アドレス入力欄のUI変更などUI改善
3.ミドルウェアをPostfixにすることでSTARTTLSに対応します
4.メール本文をRFCに準拠しました
5.不具合修正

リリースは複数回に分割して実施

以降はリリースについて説明します。リリースは複数回(複数日)に分割して行います。
理由は以下のとおりです。

・メールディーラーのサーバは複数台あり1日では終了しない
・メールディーラー内部のミドルウェアの変更があり、より慎重におこなう必要があった

リリース作業は深夜に実施します。
それはリリース中にメールディーラーのサービスが停止するからです。

「サービス停止が発生する＝お客様がメールディーラーを利用できない」ということを意味します。
ですので、お客様の日常業務に影響しないように、夜間バッチが開始される朝の4時までにリリース作業を終了しなければなりません。

そのため、リリース作業によるサービス停止時間を極力短くするために、準備作業などは事前に実施しておきます。
リリース作業は「できるだけ遅い時間に開始」し「できるだけ早く終了」する時間との戦いになるので大変な作業です。

リリースについてはまた別の記事で詳しくご紹介します。

なお2回目は5月30日の深夜を予定しています。

以上でメールディーラーの12.2の機能とリリースについての説明を終わりにします。

おまけ

現在ラクスでは新卒採用と中途採用を行っています。
サービス開発に少しでも興味がある方は下記採用サイトをご覧になり、応募をおねがいします。

ラクス採用サイト
http://fresh-recruit.rakus.co.jp/

コマンド不要で超簡単！HerokuでWebアプリ開発を30分で始める【php+postgres】

こんにちは。エンジニアのmickey-STRANGEです。
前回はめんどくさがりによるめんどくさがりのためのスマホアプリ開発についてお話したいと思います。なんて言いながら、全てをJSでごりっと無理やり解決する方法をご紹介しました。 tech-blog.rakus.co.jp はい、タイトル詐欺です、すみません。冷静に考えて、この作りのWebページが世の中にない現状、これよりも簡単な方法が必ずあるはずなんですよね（当時サンプル書きながらコレめんどくさいな、なんて思ってないです）。

今回はタイトル詐欺ではなく、Herokuというサービスを用いてWebアプリ開発の環境構築が本当に簡単に出来てしまう方法をご紹介いたします。

Heroku（へろく）とは

Herokuとは、PaaS（Platform as a Service）の1種で、アプリケーションの底にあるプラットフォームそのものを、Webを通じて提供してくれるサービスです。
今回の記事では、Heroku上でphp+postgresをプラットフォームとするWebアプリの構築、が目的となります。

Herokuで環境構築

Herokuを用いて、ということなのでHerokuのアカウント登録は完了している前提で説明を始めます。使用するのは以下の2サービスですので、アカウント登録まだだよ、という方はご準備ください。

• Heroku

jp.heroku.com

• GitHub

github.co.jp

php+postgresアプリの作成

まず最初に、Heroku上にアプリケーションを作成します。ログインして右上NewからCreate New App、もしくはアプリケーションが1つもない場合は画面真ん中にあるCreate New Appをクリックします。

アプリ名を入力し、Create appをクリックします。これでアプリケーションが作成できました。
といっても、名前と枠組みだけの状態なので、これからphp+postgresで動くアプリケーションだという設定をします。

アプリケーションのページからSettings→Add buildpackの順にクリックします。

立ち上がったポップアップの中でphpを選び、Save changesをクリックします。

これで作成したアプリケーションはphpで動きますよ、という設定が出来ました。

続いてpostgresを設定します。
Resources→Find more add-onsからHeroku Postgresを探してクリックし、Install Heroku Postgresをクリックします。

Heroku Postgresはアドオンですので、料金プランの選択があります。というと身構えてしまうかもしれませんが、Hobby Devという無料プランがありますので、これを選択します。そしてpostgresを追加するアプリケーションを選択し、Provision add-onをクリックします。

以上で作成したアプリケーションをphp+postgresのアプリケーションであるという設定が完了しました。あとはソースをデプロイすればWebアプリケーションとして稼働する状態です。

デプロイソースの指定

続いて、ソースのデプロイ元の設定をご説明します。
ソースのデプロイ元として使用するのがGitHubになります。GitHubにデプロイ用リポジトリを作成し、直下にindex.phpをpushします。

今回作成したファイルは以下のものです。php+postgresが稼働していること、phpからpostgresに接続できていることの確認が目的なので簡単なものです。

今回もGitHubへのpushはGitHub Desktopを使用しました。直感でぽちぽちできるデスクトップアプリはやはり強いですね。
GitHub Desktop | Simple collaboration from your desktop

とはいえ、これでGitHub側の操作は終わりです。Herokuの画面に戻ります。
Deploy→GitHub→Searchとクリックし、上記index.phpをpushしたリポジトリの隣にあるConnectをクリックします。

これでGitHubリポジトリからデプロイする設定が完了しました。HerokuからGitHubへの接続が初めての場合は、連携をするかどうかの確認が出ますので、表示されるとおりに進めていけばOKです。

最後に、Enable Automatic deploysとDeploy Branchをクリックしましょう。
Enable Automatic deploysは自動デプロイの設定です。ブランチを指定して自動デプロイを有効にすることで、そのブランチにpushされるたびに自動でアプリケーションを最新のソースに置き換えてくれます。
Deploy Branchは手動デプロイのボタンです。アプリケーションの設定とデプロイ元の指定をしただけで、まだデプロイはされていません。自動デプロイを有効にしたとしても、初回だけは手動で行います。

ブラウザからアクセス！

これまでの手順で全ての準備が完了しました。実際に作成したアプリケーションにアクセスしてみましょう。
アプリケーションのページの右上にOpen appというボタンがあるのでクリックしてみましょう。

作成したindex.phpの通りに表示されました！
postgresのバージョンもphpから取得出来ているのでgetAttributeの代わりにSQLを発行して動きをつけていけば立派なWebアプリケーションになりますね。

個人的な感想として、postgresが10.3と最新に対してphp5.6がツッコミどころに思えて仕方がなかったのですが、phpのバージョンを指定する方法がちゃんと用意されています。画面から作っただけではデフォルト設定で作られる、といった感じでしょうか。composer.jsonに改めて指定することでphpのバージョン変更が可能です。
Heroku PHP Support | Heroku Dev Center

【補足】phpからpostgresの接続

ここまでアプリケーション稼働までの手順をご説明いたしましたが、1つだけ補足があります。

最初、phpからpostgresに接続するにあたって、接続情報の取り方に詰まりました。Herokuの画面上から確認は出来るのです。ですが、これだけ環境構築が簡単なのに接続情報はまったく関係ないサービスであるGitHub上のソースにべた書きで持つ、というところが引っかかりました。GitHub上のソースを見れば他の人のアプリのDBにアクセス出来てしまいます。
調べたところ、postgresをアプリケーションに追加したときに、環境変数に追加されているようで、そこから取得する方法が、上記のindex.phpの記述になります。
Heroku Postgres | Heroku Dev Center

終わりに

今回はタイトル詐欺ではなく、めんどくさがりでもすぐにWebアプリ開発が出来る手順の記事になっていると思います。

Herokuを初めて使ったのですが、とても簡単で驚きました。調べるにも公式ドキュメントが多いので、詰まってどうしようもなくなるということはありませんでした。
タイトルの30分というのも嘘ではなく、「よし、やるか」と思い立ってHerokuのアカウントを作成してから、特に調べるでもなく直感でぽちぽち画面を操作して、phpinfo()を画面に出すまでの時間がそれぐらいでした。本当に簡単です。
コマンド要らずの設定の簡単さも素晴らしいのですが、特にpushからの自動デプロイがめんどくさがりの心にかなり響きました。

気を付けないといけないところは、前回の記事で作成したアプリはアクセス者本人の画面にのみデータが表示されるのに対し、Herokuは通常のWebアプリになりますので、脆弱性のあるサービスを公開してしまうと攻撃の踏み台として使われてしまう可能性があります。アプリの作成、公開は気を付けて行いましょう。

さて、これにて今回の記事は終わりとしますが、前回のタイトル詐欺の汚名を返上できたでしょうか。 最後までお読みいただきありがとうございました。

---

• エンジニア中途採用サイト
  ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
  ご興味ありましたら是非ご確認をお願いします。
  
  https://career-recruit.rakus.co.jp/career_engineer/

• カジュアル面談お申込みフォーム
  どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
  以下フォームよりお申込みください。
  forms.gle

• イベント情報
  会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

この前記事になった人に追加でインタビューしてみた

こんにちは。開発エンジニアのamdaba_sk（ペンネーム未定）です。

前回は「OWASP ZAPについて調べてみた」という記事を書きました。単体テスト中にこっそり使ってみようかと思っていたのですが、手元の環境ではポート待ち受けでエラーが出てしまって放置しています……。

それはさておき、ひと月ほど前の話になりますが、弊社エンジニアのインタビュー記事が公開されましたね。

周りから信頼されていきいきと業務に励む坂田くんの姿が伝わってきます。この記事を読んで、わたくし不覚にも「楽しそうな職場だなあ、私もそういうところで働きたい……」とちょっと思ってしまいました。いえ、別に今の職場環境に不満があるわけでもないのですが。

まだご覧いただけていない方はぜひに。

ところで実は彼は私の同期でありまして、先日お昼を一緒に食べたついでに雑談に見せかけて追加でインタビューしてみましたので、その時の話を今回は書こうと思います。 （※本人了承済み。ただし写真は気恥ずかしいのでNGだそうです。今さらな感じもしますが）

ある昼下がり

私は前回のブログ投稿からけっこう間が空いていたので、そろそろ新しい記事を投稿したいなと思っていました。技術的なTipsのようなネタもよいけれど、たまにはラクス社員である自分しか書けないようなネタが良い。そしてせっかく書くのだから自分も楽しんで書きたい。業務の傍ら頭の隅で考えるものの、しかしこれだというネタがなかなか見つけられずに少し焦っていました。

混雑を避けて少し遅めの時間帯に昼食をとるのが同期の間での習慣です。業務の切りを見て社内チャットで誘い合い、オフィスから出て外へ。その時は私と坂田くんの二人でした。

そこで、ピンときました。思い立ったが吉日ということで早速アイディアを実行に移す私。その時ちょっと顔がにやけていたかもしれません。

ペンネーム未定（以後 ペン未）「そういえばこの前インタビュー受けてた記事公開されてましたね。見ました。全国デビューおめでとうございます」

坂田くん（以後 坂田）「やめて」

ペン未「なんかめっちゃいい感じのこと言ってたじゃん。あれほんとに言ったの」

坂田「そのままは言ってない。記事の目的に合わせてかなり編集されてるし、後から修正もしたし」

ペン未「まあ、ですよね」

坂田「でもベースはインタビューの時に話した内容」

チャットディーラーのことについて

ペン未「CD¹で使ったフレームワークってなんだっけ。ら……ららばい？」

坂田「Laravel。PHPのWebアプリケーションフレームワークだね。あとJavaScriptでVue.js」

何言ってるの？ みたいな顔をしつつも坂田くんはちゃんと答えてくれます。ありがたや。

ペン未「そうでした。使ってみてどうだった？ 例えばMD²と比べてみて」

MDはCDと同じくPHPで書かれていますが、特にフレームワークは使用していないということは以前坂田くんから聞いていました。

坂田「フレームワークがあるとやっぱりかなり楽。面倒なことはやってくれてるし、どこにどんなことを書くといいのかが明確に分かれてるから、作りたい機能のことに集中できる。これはLaravelに限った話じゃないとは思うけど。他にフレームワークを触ったことが無いから他のフレームワークと比べてってなるとよくわからない」

ペン未「Vue.jsは非難殺到だったって話だったよね」

坂田「あー、うん、慣れるまではちょっと大変だったかな。それまで慣れ親しんだ手続き的なJSの書き方とはパラダイムが違うというか。Vue.jsっぽい書き方ってどんなだろうってはなった。開発入る前にもちょっとは勉強してたけど、実装始めてからも公式サイトのドキュメント読んでることが最初のうちは多かった」

ペン未「へー……。先輩に教える場面もあったって記事には書いてあったよね」

坂田「みんなして慣れてなかったからね。LaravelもVue.jsも。何か新しくわかったことがあったらけっこう教えあってた。Laravelだとこう書けばいいみたいですよー、とか、Vue.jsでこう書くとそれたぶんうまくいきます、とか」

話しているうちにオフィス近くの定食屋さんに到着し、食券を購入するために話は一時中断となりました。

かみせん

ペン未「そういえばCDは全社交流会³で表彰されてましたよね」

坂田「そうですね」

ペン未「そういえばあなたもういっこ表彰されてませんでしたっけ。なんででしたっけ」

坂田「そうですね。かみせんプロジェクトですね」

ペン未「それ前から思ってたんだけど、かみせんって結局なにしてるの」

坂田「目標は、なんだっけ……新しい技術とかにチャレンジして、わかったことを普段の業務の改善に活かすこと。具体的にはQCポータル⁴の段階的マイクロサービス化を今やってるとこで、私はマイクロサービス一つの実装をやってた」

Haskell……？

ペン未「それでHaskell？」

坂田「そうね」

ペン未「なんでHaskell？」

坂田「え、なんかかっこいいから……純粋関数でプログラム書くのってなんか良さそうじゃない？　変なところに副作用が出ないから修正のための影響範囲の調査だって楽そうだし、もし影響があるなら型検査で引っかかるだろうからすぐわかるし」

ペン未「でもそれでアプリケーション作るとかイメージできないんだけど」

坂田「それはライブラリがあるから大丈夫。この前ビアバッシュ⁵で紹介した本⁶にはWebアプリケーションを作る章もあるし簡単なAPIサーバーくらいならすぐに」

ペン未「っと、そろそろ時間やね。行きましょうか」

そして仕事はつづく

Haskellについて熱く語ってもらえそうな感じになっていましたがあいにくと時間切れ。ごちそうさまと告げて店を出、そのあとは他愛もない話をしつつオフィスに戻りました。午後の業務が始まります。

自席について先ほどの話の内容をメモしつつ、私が思ったのは一つでした。

Haskell好き、増えるといいね……

---

1. Chat Dealer（チャットディーラー）の略称。CDについて詳しいことは商品サイトを参照 → https://www.chatdealer.jp↩

2. Mail Dealer（メールディーラー）の略称。MDについても詳しいことは商品サイトを参照 → https://www.maildealer.jp↩

3. 年度末に開催される全社員が集まってのパーティ。その年度に特に活躍したりした個人・グループが表彰されたりする。↩

4. 社内用システムのひとつ。いくつか機能はあるが、もっぱらその日の仕事はどんなことを何時間やったか入力のために利用される↩

5. 月1で開催している開発部の交流会。ビールなどのアルコール(+軽食)を片手にフランクに技術内容について発表したり語り合ったりする。このブログ内でも過去に紹介された。↩

6. 本間 雅洋, 類地 孝介, 逢坂 時響 (2017)「Haskell入門 関数型プログラミング言語の基礎と実践」技術評論社↩

新人がDockerを学習すべき4つの理由

Y-Kanohです。 社会人になって2年とちょっとが経ちました。

私は、入社してから、会社で得た知識など、新しい技術を試す際、Dockerを使って開発環境を構築しています。 Dockerというと、その手軽さと管理のしやすさから、非常に注目されていますが、新米エンジニア目線だと、技術学習のツールとして大変重宝する点がとても多く感じます。

今回は、新米のエンジニアがDockerを学習することでよかったと感じたことを4つまとめます。

その1：軽量な開発環境として使える

Dockerとは仮想化技術の1つです。 と言っても、VirtualBoxなどのようなホスト型仮想化ではなく、コンテナ型仮想化技術です。 使い古された図ですが、下図のように、 コンテナ型仮想化では、ホスト型仮想化と違い、 ゲストOSを用いず、OS上の区切られたコンテナと呼ばれる空間で動作するプロセスとして仮想空間を扱うことができます。 そのため、ホスト型仮想化より軽量で、CPUやメモリの使用量も抑えることができます。

新米のエンジニアとして、自宅で必要になるものは、自分が自由に扱うことができる開発環境です。 会社で得た技術を試したり、ちょっとした下調べ、さらには自宅での開発を行うには、開発環境が必要ですが、 重い仮想マシンを立ち上げることはあまり得策ではありません。さらに、サーバを複数台用いた開発を行いたい場合は...

最初からハイスペックなコンピュータを持っている場合は別ですが、スペックが限られたコンピュータしかもっていない場合なおさらです。

その2：使用するMWを意識できる

Dockerは"Infrastructure as Code"と呼ばれる、インフラ環境をコード化して管理することができる仕組みを提供してくれます。 具体的には、「Dockerfile」と呼ばれるファイルに、コンテナを構成するOSやMWを記述し、「Dockerfile」を基にコンテナを作成することで、何度でも同じ環境を構築することができます。

以下は簡単なPHP環境を構築する際に使用したDockerfileです。とくに難しいことが書いてあるわけではなく、使いたいMWのインストールコマンドがほとんどなため、知識がなくてもハードルは高くありません。。

FROM php:7.2.0-apache

RUN apt-get update
RUN apt-get install -y libpq-dev && docker-php-ext-install pdo pdo_pgsql mbstring

RUN a2enmod rewrite

## 設定ファイルの追加
ADD ./config/000-default.conf /etc/apache2/sites-available/000-default.conf
ADD ./config/php.ini /etc/php.ini

# タイムゾーンの設定
RUN cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

CMD apache2-foreground

あまり知識がないうちの開発では、自分が一体どのMWやライブラリの機能で実装できているのかわからなくなる時があります。 私の場合、自宅の仮想マシンでできていたことが、実はOSにたまたまインストールされていた機能だったのに、知らずに使っていたということもありました。

元々、「Dockerfile」はインフラ環境をコードとして管理することで、MWのバージョン管理や、デプロイの効率化などが目的かと思います。 ですが、学習目的としての環境構築時には、自身が必要とするMWがなんなのか、何の機能を使って開発を進めるのかを自覚することができます。

Dockerfileは、自身の構築する環境をしっかり意識するためにも、役に立つのではないでしょうか。

その3：まっさらな開発環境がすぐ手に入る

学習目的の開発を行う上でありがちなのが、様々なライブラリやMWを試すうちに、 なにをどうインストールしたのかわからず、開発環境が修復できない状態になってしまうことです。 少なくとも、私はそうでした。 インストールしたMWは覚えていない、バージョンもよくわからない、といった状況です。

そのたび、開発環境をリセットするために、OSをインストールしなおすのは、時間もかかり、それに伴ってモチベーションもなくなるため、あまりにナンセンスです。

Dockerでは、「Dockerイメージ」と呼ばれるコンテナのテンプレートのようなものを保存することができます。 「Dockerイメージ」はホスト型仮想マシンのスナップショットのように容量も大きくなく、 コマンド一発ですぐコンテナを作ることができます。 「Dockerイメージ」は、先に触れたDockerfileから作ることもできますし、 インターネットには、たくさんの「Dockerイメージ」が公開されています。

もし、開発環境の構築でいろいろ試したい場合は、ベースとなるOSのコンテナを作成し、 気になったMWをインストールして、うまくいかなかったらすぐ破棄してもう一度コンテナを作り直すといったことを、 短いスパンで繰り返すことができます。

そのため、ツールの選定時には、とても重宝しますし、気軽にトライアンドエラーを行うことができます。

その4：さまざまなOSSツールを試すことができる

Dockerの利点は、なにも開発環境の構築だけではありません。 主要なOSSは、公式のDockerイメージを公開しています。 たとえば、redmineやGitLab、Jenkinsなど、Dockerイメージが用意されており、 コマンド一発で手元にデプロイすることができます。

そのため、もし、配属されたチームにて使っているツールについて、わからないことがあった場合、 自宅でそのツールをデプロイして、自分でいろいろ試すことができます。 私の場合、チームで使い始めたGitLabを自宅で立ち上げ、普段使っていない機能を触ったりしています。

チームで使用しているツールは、開発の中で使いこなせるようになるとは限りません。 かといって、チームで使っているツールを学習目的で弄るわけにもいかないので、自宅で簡単にデプロイし、自由に使える環境はとても重要です。

おわりに

私の場合、最初にDockerを学習したきっかけは、上記のような学習目的ではなく、単純な興味でした。 しかし、Dockerを学習したおかげで、自宅での開発や学習に対して、フットワークが軽くなったと感じています。

Dockerの知識が業務に直接役に立たない場合でも、自身のスキルアップのために、学習してみたらどうでしょうか。

Swiftのクロージャについて

はじめに

こんにちは。ラクスエンジニアのstrongWhiteです。
今回はSwiftにおけるクロージャの書き方をまとめようと思います。
クロージャはJavaScriptなどを勉強した方は馴染みがあるかもしれませんが、初めての方は慣れるまで時間がかかるかもしれません。
なお、今回はSwift自体の説明を省きます。過去の記事でSwiftについて触れているので、気になる方はそちらをご参照ください。

クロージャとは

まずは前置きから。そもそもクロージャとは？ですが、簡単に言うと名前のない関数です。
文章にすると余計に混乱されるかもしれませんが、あえてまとめるなら以下のような感じでしょうか。

• 自身が定義されたスコープ内で解決する関数
• 実行結果を次の処理で続けて使用する関数を作成したい場合に使用

これを読んでも意味不明だと思いますので、後ほどサンプルコードを書いてみます。

コールバックとは

クロージャとは直接関係ありませんが、この後のサンプルコードにコールバック関数が出てくるので、コールバックとは？という方のためにあらかじめ解説しておきます。
コールバックとはあとで呼ぶという意味で、呼び出し先の関数の中で実行されるようにあらかじめ指定しておく関数をコールバック関数と言います。関数の中で別の関数を呼ぶイメージです。

実例（通常の書き方）

それではサンプルコードを見ていきましょう。まずは通常の書き方から。単純な文字列を出力するプログラムです。

func A() {
    print("RAKUS Developers Blog", terminator: "")
    B()
}
        
func B() {
    print("を読んでラクスを知ろう")
}
        
A()

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

実例（クロージャの書き方）

続いてクロージャを使ったサンプルコードです。処理内容は通常の書き方と変わっていません。

func A(title: String, callback: (String) -> (String)) {
    print(callback(title) + "ラクスを知ろう")
}

A(title: "RAKUS Developers Blog") { (blogName) in // <--クロージャ
    return blogName + "を読んで"
}

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

ややこしそうですが簡単に処理の流れを解説すると、関数Aの実引数titleの値がcallbackの引数になる＝blogNameの引数になります。
そしてRAKUS Developers Blogにを読んでが足された文字列がreturnされ、関数Aの処理でさらにラクスを知ろうが足され、最終的な文字列が出力されることになります。
高度な書き方に見えますが、Swiftをやっているとよく出てくる書き方なので覚えておいて損はないです。
このとき、関数Aのcallbackが前述したコールバック関数です。関数Aで呼び出されて初めて処理が行われます。

クロージャにすると何がよいのか？

最初に書いたように実行結果を次の処理で続けて使用する関数を作成したい場合に有効です。
例えば、ダウンロードしたCSVファイルを返す関数downLoadCsvがあるとします。サンプルコードでいうとdownLoadCsvは関数A相当になります。
downLoadCsvから返されたCSVファイルをもとに後続の処理を行いたい（例. CSVファイルをパースする）場合、クロージャでdownLoadCsvの返り値を記述してあげれば実行結果を引き継げます。
慣れるととても使いやすく、記述もシンプルになるので、クロージャの書き方をぜひマスターしてみてください。