こんにちは。west-cです。 早いもので 1エントリ目の記事 から1年が経とうとしており、自チームにも今年の新卒メンバーが配属されました。 そこで今回も、今年入社の新米エンジニアの方を対象に、個人的に業務でよく使うツールを紹介したいと思います。 私自身もまだ4年目で新米に属する部類ではありますが、少しでも業務効率化に寄与できれば幸いです。 WinMerge WinMerge 日本語版 テキストファイルの差分比較・マージを行える有名なソフトウェアです。 修正前後の差分チェックを行い、意図通りの修正となっているかを確認するために利用しています。 目diff *1 ・目 grep は特殊な訓練を受けた上で実施しないと思わぬ事故に繋がります。正確な結果を得るためにツールを活用しましょう。 Sublime Text Sublime Text - A sophisticated text editor for code, markup and prose ソースコード エディタです。 コーディングは IDE を利用しますが、ちょっとした スクリプト を見たり 正規表現 を用いた検索・置換をサクッと行いたい場合に利用しています。 Visual Studio Code や Atom などのエディタでも同様のことは行えますが、動作が一番軽快なため私はこのエディタの利用頻度が一番多いです。 指定フォルダ下の全ファイル文字列検索（ grep のようなもの）も行えます。 Awesome Screenshot Awesome screenshot ブラウザの画面キャプチャが行えます。 撮影範囲の指定や文字挿入などある程度の画像編集も行えるため、そのまま Mattermost *2 や Redmine に貼り付けて利用しています。 ScreenToGif （↑実際に動画撮影をした様子） ScreenToGif - Record your screen, edit and save as a Gif or video 画面を動画撮影し、GIF形式で保存できます。 自チームでは発見したバグを Redmine のチケットで管理しています。 バグ報告時に再現手順を文章で説明するのが難しい場合には、その手順を撮影したGIF画像もチケットに添付しています。 動画だと操作手順が分かりやすく認識齟齬も起きにくいため、チーム内でもよく利用されています。 Boostnote Boostnote | Boost Happiness, Productivity, and Creativity. Markdown 形式でメモを取ることができます。 日々のタスクやちょっとしたtipsなど、基本的にここで一元化するようにしています（手帳に取ったメモもこちらに清書しています）。 タグ付けやフォルダ分け・検索も行えるため過去のメモも追いやすく、「メモした記憶はあるけれど、どこに書いたか忘れた」という事態がほぼ無くなりました。 Postman Postman | API Development Environment WebAPIに対して GUI で直感的にリク エス トを送信できます。 少し API のテストを行いたい場合に curl コマンドを打つことなくサクッと実施できるので重宝しています。 自分で作成したリク エス ト情報をインポートすれば、プログラムに詳しくない方でも簡単に API のテストやお試しができる点も魅力です。 おわりに これは個人的意見ですが、 面倒なこと・正確さが求められることはコンピュータに任せる という意識はエンジニアとして重要だと思っています。 （「 プログラマ の三大美徳」という有名な言葉にも繋がると思います） ぜひ非効率だと思う部分があればツールの導入等で効率化を試みてください。 そして、場合によっては自分で作成してみるとさらに良いと思いす。 自分が欲しかったものを自分の手で作ることができるのは、エンジニアならではの醍醐味だと思いますよ！ エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : Linux コマンドの diff 相応の差分比較を目視で行う特殊技能のこと。目 grep も同様。 *2 : チャットツールとして有名な Slack に似たツール。自チームではチャットツールに Mattermost を導入しています。

はじめに 新卒2年目エンジニアのkasuke18と申します。 今回はLINEでメッセージを送信することで Twitter 検索を行うLINE Bot を作成してみましたので、作成の流れや実際のコードを記載します。使用言語は PHP です。 もくじ はじめに 構成 必要なもの 実装例 メッセージの取得 Twitterで検索 検索結果のパース LINEに送信 おわりに 参考文献 構成 今回はLINEの API と Twitter の API を利用します。また、LINEで送信されたテキストに対して処理を行うWebhook スクリプト を設置する SSL 対応のサーバが必要なため、HEROKUを使用しています。 イメージとしては以下のようになります。 必要なもの LINE Messaging API Twitter REST API HEROKU Twitter 連携パッケージ mpyw/cowitter API を利用するまでの流れについては、LINE Messaging API は 公式サイト に詳しい説明が記載されています。 また、 Twitter REST API は公式サイト上のどこに記載されているか発見できませんでしたが、検索すればそのあたりのことが書かれている導入記事が数多くあるので省略します。 HEROKUの使用方法については当ブログに記事がありますので、ぜひそちらをご参照ください。 実装例 メッセージの取得 まずはLINEから送信されたメッセージテキストを受け取る部分です。 LINE Platformから送信されるのは JSON で、以下のような形式となっています。 { " events ": [ { " type ": " message ", " replyToken ": " ********** ", " source ": { " groupId ": " ********** ", " userId ": " ********** ", " type ": " group " } , " timestamp ": 1529822351422 , " message ": { " type ": " text ", " id ": " ********** ", " text ": " 送信メッセージ " } } ] } 上記の JSON をもとにパースして送信されたテキスト情報を取得するコードが以下となります。送信される形式が JSON なので、 $_POST ではデータが取得できないことに注意が必要です。 <?php $ json = json_decode ( file_get_contents ( 'php://input' ) , true ) ; $ message = $ json [ 'events' ][ 0 ][ 'message' ] ; $ messageText = $ message [ 'text' ] ; Twitter で検索 次に受信したテキストをキーワードとして、 Twitter で検索します。 Twitter の連携については自前でやってしまうのもありですが、 面倒なので Twitter 連携パッケージ mpyw/cowitter を使用しています。 <?php $ client = new Client ([ $ consumerKey , $ consumerSecret , $ twitterAccessToken , $ twitterAccessTokenSecret ]) ; $ tweetsParams = [ 'q' => $ q . ' -rt' , 'count' => '10' , 'result_type' => 'recent' , "include_entities" => true ] ; $ tweets = $ client -> get ( 'search/tweets' , $ tweetsParams ) -> statuses; $tweetsParams で検索条件を指定します。 q は検索キーワードで、検索 演算子 も利用できます。今回は リツイート を排除したいので、検索 演算子 -rt を使用しています。 count はそのまま検索結果の取得件数で今回は10件、 result_type は取得するツイートの種類で recent とすることで最新のツイートを取得します。 最後の include_entities は少し特殊で、取得したツイートオブジェクトにentitiesプロパティを含めるかどうかを指定します。entitiesプロパティとはツイート本文を拡張するエンティティで、画像や動画などの本文に付け足すための情報が格納されています。今回はツイートに付随する画像のURLを取得するために使用しています。 他にも設定可能なプロパティがありますが、今回は不要なので省略します。必要に応じて こちら をご参照ください。 検索結果のパース 検索結果から必要な情報を抜き出すときにも、 mpyw/cowitter が当然ながら活躍してくれます。 今回必要とする情報は ツイート本文 ・ ユーザ名 ・ ツイートURL ・ 画像URL です。それぞれの情報は以下のようにして取得します。 <?php foreach ( $ tweets as $ tweet ){ $ text = $ tweet -> text; $ name = $ tweet -> user -> name ; $ url = 'https://mobile.twitter.com/' . $ tweet -> user -> screen_name . '/statuses/' . $ tweet -> id_str; $ img = $ tweet -> extended_entities -> media [ 0 ] -> media_url_https; } ここで注意する点が2つあります。 まず１つ目はツイートURLです。これはツイートオブジェクトの中に直接記載されていないので、その他の情報を結合して作成する必要があります。 ２つ目は画像URLです。画像のURLは２種類あり、 media_url と media_url_https があります。見ての通りHTTPか HTTPS かが違うだけなのですが、LINEの API が HTTPS でないとダメなので、 media_url_https のURLを取得する必要があります。 LINEに送信 最後にLINEに送信します。単に動かすだけならプレーンテキストでもよいのですが、今回は少し見た目にこだわって Flex Message という形式にしてみます。 Flex Message では複雑なレイアウトを自由に作成可能です。今回は以下のような見た目にしました。ほかにどのようなレイアウトにできるのかは、サンプルなどもありますので 公式ページ をご参照ください。 以下が今回の見た目を作成するのに必要な情報を設定した配列です。この配列を json_encode して送信します。 function toggleFold(){ if(document.getElementById('fold').style.display=='none'){ document.getElementById('fold').style.display='block'; document.getElementById('link').text='◀クリックで閉じる'; } else { document.getElementById('fold').style.display='none'; document.getElementById('link').text='▶クリックで開く'; } } ▶クリックで開く <?php $ messageData = [ "to" => $ groupId , "messages" => [ [ "type" => "flex" , "altText" => $ altText , "contents" => [ "type" => "bubble" , "hero" => [ "type" => "image" , "url" => $ img , "size" => "full" , "aspectRatio" => "20:13" , "aspectMode" => "cover" , "action" => [ "type" => "uri" , "uri" => $ img ] ] , "body" => [ "type" => "box" , "layout" => "vertical" , "contents" => [ [ "type" => "text" , "text" => $ name , "weight" => "bold" , "size" => "xl" ] , [ "type" => "box" , "layout" => "vertical" , "margin" => "lg" , "spacing" => "sm" , "contents" => [ [ "type" => "box" , "layout" => "baseline" , "spacing" => "sm" , "contents" => [ [ "type" => "text" , "text" => $ text , "wrap" => true , "color" => "#666666" , "size" => "sm" ] ] ] ] ] ] ] , "footer" => [ "type" => "box" , "layout" => "vertical" , "spacing" => "sm" , "contents" => [ [ "type" => "button" , "style" => "link" , "height" => "sm" , "action" => [ "type" => "uri" , "label" => "See Tweet" , "uri" => $ url ] ] ] , "flex" => 0 ] ] ] ] ] ; そして実際に作成したメッセージを送信する部分のコードが以下となります。 改めて説明するまでもなく、 curl をたたいて終わりです。 <?php $ ch = curl_init ( "https://api.line.me/v2/bot/message/push" ) ; curl_setopt ( $ ch , CURLOPT_POST, true ) ; curl_setopt ( $ ch , CURLOPT_CUSTOMREQUEST, 'POST' ) ; curl_setopt ( $ ch , CURLOPT_RETURNTRANSFER, true ) ; curl_setopt ( $ ch , CURLOPT_POSTFIELDS, json_encode ( $ postData )) ; curl_setopt ( $ ch , CURLOPT_HTTPHEADER, array ( 'Content-Type: application/json; charser=UTF-8' , 'Authorization: Bearer ' . $ accessToken )) ; $ result = curl_exec ( $ ch ) ; curl_close ( $ ch ) ; おわりに 特に需要はないでしょうが、今回はLINEから Twitter 検索をしてみました。単に API をたたくだけで多くのことができます。今回はテキストメッセージを検索するということしかしていませんが、もっと面白いものがあれば機能拡張という形で取り込んで行きたいです。 最後までご覧いただきありがとうございます。 参考文献 LINE developers: Messaging API を利用するには https://developers.line.me/ja/docs/messaging-api/getting-started/ Docs — Twitter Developers https://developer.twitter.com/en/docs.html Heroku Dev Center https://devcenter.heroku.com/ GitHub - mpyw/cowitter: Asynchronous Twitter client compatible with mpyw/co Generator-based flows. https://github.com/mpyw/cowitter GET search/tweets - ツイートを検索する https://syncer.jp/Web/API/Twitter/REST_API/GET/search/tweets/ LINE developers: Flex Messageの要素 https://developers.line.me/ja/docs/messaging-api/flex-message-elements/

MasaKuです。 ラク スでは月１回のペースで開発メンバーの交流会としてビアバッシュを開催しています。 ビアバッシュとは ビールなどのアルコールを片手に(+軽食)フランクに技術内容について発表したり語り合う交流会 です。 ラク スで行っているビアバッシュについては以下の記事が参考になるかと思いますので、よろしければご確認下さい。 tech-blog.rakus.co.jp tech-blog.rakus.co.jp 大阪開発部では毎月何らかのテーマを決めてビアバッシュを行っています。 今月、大阪の開発部で開催されたビアバッシュのテーマは「 技術ネタ 」です。 技術ネタといっても、硬い雰囲気は全くなく、業務に直接関係しないような内容について発表されている人がほとんどでした。 また、テーマに縛られないLT枠も毎回開催されており、こちらも毎回数名の方が発表しています。 簡単ではありますが、今月のビアバッシュの雰囲気をお伝えできればと思い、発表内容についてまとめさせていただきました。 テーマ枠（技術ネタ） PHPのマジックメソッドについて これまでのPWAとこれからのPWAについて Haskellの参照透過性について LT枠（自由発表） 使い続けているツールについて Googleのデータセンターについて Android Studio で作ったアプリについて おわりに 参考サイト ビアバッシュの様子。ちなみに、今回のケータリングは「サンドイッチ」でした。 テーマ枠（技術ネタ） PHP のマジックメソッドについて マジックメソッド とは、クラスに設定しておけば、明示的にメソッドを呼び出さなくても特定条件で自動的に発動するメソッドのことです。 __construct() は業務の中でもよく目にしますが、それ以外のマジックメソッドについては、 PHP の学習初期に利用していた参考書に紹介されていたものを少し読んだくらいで、ほとんど知りませんでした。 マジックメソッドは フレームワーク やライブラリの中で利用されていることが多いようで __call() や __get() は CakePHP でも利用されているようです。 発表は __callStatic() を中心とした内容でしたが、機能の説明だけでなく、どのように実装するかということを、書籍管理を例にして説明していただきました。 発表の時間内でライブコーディングするというテクニックも披露していただき、大変見ごたえのある発表でした。 これまでのPWAとこれからのPWAについて Progressive Web Apps については、Webアプリでありながら、ネイティブアプリのように振る舞うことができるもの、くらいの認識でした。 また、どこでもネットに繋がる現代において、オフライン環境でも利用できることのメリットはそこまで大きくないのではないかと考えていました。 しかし、データを端末にキャッシュすることで、アプリのレスポンスが早くなるという点もPWAの特徴であるということについてご指摘いただき、オンラインで通信する必要のある箇所を切り分けるという観点を見落としていました。 様々な フレームワーク でPWAのテンプレートが利用できるようになってきている（React.js / Vue.js / Angular.js）ことから、PWAの開発が加速化することが期待されます。 Microsoft が今年中にPWAをWebアプリストアに追加することを発表したこともあり、今後のPWAのニュースにも注目しておかなければなりません。 www.itmedia.co.jp Haskell の参照透過性について Haskell の参照透過性のメリットについての発表内容でした。 なお、本発表は発表者とは異なる方が作成された資料を参照しながらの発表でした。（下記の slideshare ） 関数を実装する際に気をつけなければならないこととして、その関数がどのような値を受け取ってどのような値を返すのか、ということを明確に意識しておくことが挙げられます。 Haskell は静的型付き言語の中でも、制約が強い プログラミング言語 に分類されるようです。 そのため、実装した関数が正しい型で設定されていない場合は、 コンパイル 時に失敗するが、裏を返せば、 コンパイル で落ちなければ、関数の型が正しく設定できていることが保証されるということでもあります。 発表者の方は、 Haskell のような強い静的型付き言語でプログラミングを行うことによって、 PHP などの制約の優しい プログラミング言語 でプログラミングをする際にも型を意識する癖がついたとおっしゃっていました。 実装する際の心構えだけでなく、体に癖をつけておくことは大切だなと思いました。 Haskell Day2012 - 参照透過性とは何だったのか LT枠（自由発表） 使い続けているツールについて 業務で使っているツールを２つ紹介してくださいました。 Wireshark ネットワークに流れるパケット情報をリアルタイムで調査できるツールです。 Linux のコマンドも利用できることに利便性を感じて、今でも利用されているようです。 knowledge.sakura.ad.jp Vimium ブラウザ操作をキーボードで行うためのツールです。 マウスを操作しなくても ブラウジング ができることから、キーボードから手を離したくないような場合に便利で、体感的にはすごく楽とおっしゃっていました。 なお、以前のビアバッシュでこちらのツールと同様の cVim という Google Chrome の 拡張機能 の発表をしている方もいらっしゃいました。 マウス無しで ブラウジング することの需要は一定存在するようですね。 Google のデータセンターについて Google のサーバは、サーバを構成するビス1つから Google が自社で作成しているようです。 なんでも、利用している製品に 脆弱性 が発覚した際に攻撃されるリスクを回避するためなんだとか。 また、本発表で面白いと思ったのが、サーバの維持管理で一番コストがかかる箇所が、空調管理のための電力だそうです。 PUE(Power Usage Effectiveness)という、データセンターのエネルギー効率を表す一つの指標がありますが、 Google ではこのPUEが1.12～1.19程度らしいです。（ 業界標準 は1.5程度） 以前耳にした話ですが、 さくらインターネット では北海道の冷涼な外気を サーバル ーム内に取り込むことで、一般的な都市型データセンターと比較して約4割の消費電力を削減しているそうです。 サーバの維持管理のコストをいかに抑えるか、という話を聞くことで、 Google 検索を行う度に Google の電気が一部利用されているということをちゃんと意識できるようになりました。 提供されているサービスとはいえ、無駄なクエリ発行はできる限り抑えなければなりませんね。 www.sakura.ad.jp Android Studio で作ったアプリについて 業務で行った内容の復習として取り組まれた、 cURL で外部サーバにアクセスして情報を取得する Android アプリの開発について発表していただきました。 アプリの内容は Wather Hacks という Webサービス の API を用いて、その日の天気情報を取得するといったものでした。 本アプリを開発する上での苦労話として、 Android はOSのバージョンアップによって仕様が変わることから、参考にしている記事がどのバージョンの Android を対象とした記事なのかをしっかりと確認しなければ、うまく動作しなかった、ということを話されていました。 これは、自分が情報を収集する際のポイントとして、気をつけなければならないことでもあります。 しかし、新たに情報を発信する際も、環境依存となる情報は明確に提示しておくことで、記事の価値を高めることに繋がることを認識することができました。 tech-blog.rakus.co.jp おわりに いかがでしたでしょうか。 今月も様々なタイプの発表が聞くことができて、大変充実したビアバッシュになりました。 次回のテーマは「 使用しているツール特集 」ということで、次回も魅力あふれる発表が聞けるのではないかと今から楽しみです。 参考サイト 便利だけど使いどころが難しいPHPの代表的なマジックメソッドと無名関数の使い方：PHPオブジェクト指向プログラミング入門（4）（1/3 ページ） - ＠IT PHP: マジックメソッド - Manual モバイルウェブアプリケーションの新しい形「プログレッシブウェブアプリ」 | DATA INSIGHT | NTTデータ Haskell Day2012 - 参照透過性とは何だったのか Wireshark · Go Deep. Vimium - Chrome ウェブストア Wiresharkを使った通信監視（後編）――コマンドラインベースでのパケットキャプチャ | さくらのナレッジ さくらインターネット、新しい空調コンセプトで石狩データセンター3号棟を建設 | さくらインターネット livedoor

id:radiocat です。 スクラム マスターの修行中です。 今回はチーム力を高めるために私たちが取り組んでいる手法を紹介します。 アジャイル のプ ラク ティスとして紹介されている手法ですが、 アジャイル ではない開発の現場でも活用できるのでぜひ参考にしてみてください。 学びにフォーカスしてチームで試験問題を作る この手法は「 スクラム 現場ガイド」という書籍の第20章で、新しいメンバーを受け入れる手法として紹介されています。 スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本- 作者: Mitch Lacey マイナビ出版 Amazon この書籍を翻訳されている安井さんが同様のテーマのスライドも公開されています。 "Test" New Members / チームメンバーを"テスト"する from Yasui Tsutomu www.slideshare.net 目的 チームが大事にしている文化や技術について繰り返しテストをすることで新しいメンバーにそれらを理解してもらいます。また、テストをすることで新メンバーの理解が足りていないことを既存メンバーも含めてお互いに認識することができます。 やりかた チームが問題を作る 新しいメンバーは毎週必ずテストを受ける 問題の例 システムの アーキテクチャ を説明してください ペアプログラミング とTDDの意義を教えてください コードの所有者は誰ですか？ チームに取り入れよう 私たちのチームも新しいメンバーを迎えることになったので、早速この手法を取り入れようと考えました。しかし、ここでいくつか疑問が浮かびました。 テストするのは新しいメンバーだけ？ テストは新しいメンバーだけに必要なものでしょうか？我々エンジニアは新しく作った機能を必ずテストしますが、そのテストを日々回帰的に利用する手法を取り入れています。同様に スクラム チームも定期的にテストすればよりチーム力を高められるのではないかと考えました。 テストという言葉のハードルが高い 新しく入ってきたメンバーに対して「これからテストしますよ」と言うのは少し仰々しく、これから一緒にやっていこうというのに逆に 心理的 な壁ができてしまいそうな気がしました。そもそもこのテストは「チームが大事にしている文化や技術について理解する」ことが目的であり「テストする」のは手段でしかありません。無理にテストという言葉を使う必要もないので余計な 心理的 障壁を作らないように「クイズ」という呼び方にしてはどうかと考えました。その名も「Scrum Quiz」です。 Scrum Quizとは 私たちはScrum Quizを以下のように定義しました。 スクラム チームを前進させるための質問集です 以下のような内容について質問に回答することで相互理解を図ります 文化 価値観 必須スキル・理論 クイズはみんなのものなのでチームの誰でも追加・更新できます クイズの内容を考える あとは問題を作るだけです。 インセプション デッキにまとめた内容やチームで決めている品質の基準などを質問するようにします。また、ふりかえりで決めたルールなども質問に加えました。ふりかえりの時にチームで決めたルールがいつの間にか形骸化してしまうことが時々あります。クイズの問題にしておけばチームでそのルールを意識することができて、定着につなげることができます。 また、理解や定着が目的なので一言で答えられるようなクローズドな質問ではなく、あえてやや曖昧でオープンな質問にしてみました。 Scrum Quizの完成 そして私たちのチームのScrum Quizが完成しました。 チームの朝会（デイリー スクラム ）後に数分ほど時間をとってメンバーの誰か1人がクイズを引いて答えてもらうようにしました。正しく答えられることも大事ですが、チームで「ああ、そういうルールだったよね」という理解が共有されることも大事です。「補足すると、ふりかえりでこういう意見がでたのでこういうルールにしました」というような話が出ればさらに理解が深まって良いと思います。また、もしクイズに答えられなかったら、次の日のまでに答えをみつけて朝会で共有してもらいます。 チームを継続的にインテグレートする Scrum Quizはチーム力を高めるためのテストです。これを日々実行することで継続的にチームの大事にしている文化をより強化することができます。エンジニア的な言葉で言い換えるとチーム力を高めるためのCIツールなのです。 アジャイル な現場に限らずどんなチームでも大事にしている文化やルールはあると思います。チームでテストを作っておけば、それらを確認し合ってチーム力を高めることができます。

はじめに こんにちは。 @rs_tukki です。 先日、このエンジニアブログでY-KanohさんがDockerでの開発環境構築について説明されていましたね。 tech-blog.rakus.co.jp また、mickey-STRANGEさんはHerokuを使った開発環境の構築を行っていました。 tech-blog.rakus.co.jp 恥ずかしながら、一エンジニアとしてもう1年以上が経過している私ですが、業務以外でガッツリ開発することがあまりありません... 環境の構築についても色々手法があるなー程度で見ていたのですが、 先日 Vagrant というツールを使って、「どの」、「誰の」、「どんな」環境でも手軽に開発環境を構築できる手順を学びましたので、今回はそちらについて簡単に記事にしたいと思います。 はじめに Vagrant？Docker？ VagrantとDockerで誰でも使える開発環境を構築してみる 必要なツールのインストール Vagrantfileの作成、VMの起動 Dockerイメージの取得 実行 おわりに 参考 Vagrant ？Docker？ まず初めに Vagrant とDockerで開発環境を構築するにあたっては、当然ですが Vagrant とDockerがどのようなツールなのか、ということを理解しなければなりません。 正直自分も違いがよくわからないまま触っていたのですが...調べていると 面白い例え を見つけました。 Vagrant : 家の内装、全体的な設計 - どんな室内構造か、部屋は何があるのか～その他 Docker : 部屋or（キッチンも可） - 様々な種類がある、場合によってば独特な空間を持ち合わせている Vagrant は、設計図を基に自分のPCに仮想環境という「家」を作成するためのツールです。 普通に環境を作ろうとした場合は、どういう階層構造にするか、どんなOSを使うのか…等々、都度細かく設定しなければなりませんが、それらの設定を Vagrantfile としてテキスト形式で保存しておけば、それを元に どんなPCからでも同じような仮想環境を作成できる のです。 Dockerに関してはこのブログでも何度か説明されていますが、今回の場合では、 Vagrant から作成された「家」の中に作られた部屋 *1 というイメージで説明します。 それぞれ作られたコンテナの中にはそれぞれ単独で機能する仕組みがあり、例えばそれがWebサーバならWebにアクセスできる仕組みがありますし、DBであればデータを保存する仕組みがあります。また、それぞれのコンテナの間にネットワークという通路を作っておけば、複数のサーバを用いるようなWebアプリケーションも簡単に作成できるというわけです。 そして最も便利なのは、このコンテナ自体も Vagrant と同じく Dockerfile を作成しておくことによって、 細かい設定なしにいきなりコンテナを配置する ことが出来るという点です。 Vagrant とDockerで誰でも使える開発環境を構築してみる では、VargrantとDockerを用いて、実際に開発環境を作成してみましょう。 必要なツールのインストール まずは必要なソフトとして Vagrant と、仮想環境を作成する際に必要となる VirtualBox をインストールします。 Dockerは？　となるかもしれませんが、Dockerをインストールするのはあくまで Vagrant で作った仮想環境 に対してなので、現時点でのインストールは不要です。 Vagrant by HashiCorp Oracle VM VirtualBox 特にこだわりがなければ、最新版でOKです。 画面の指示に従ってインストールしてください。 Vagrantfileの作成、 VM の起動 インストールが完了したら、早速仮想環境の元となるVagrantfileを作ってみましょう。 ちなみに今回の手順は、 windows での操作を前提にしています。予めご了承くださいm(__)m。 まずは コマンドプロンプト を開き、 適当な作業用フォルダを作成します。 mkdir vm\test cd vm\test 作成したこのフォルダの中にVagratfileを作成していきます。 本来であれば vagrant initコマンドでテンプレートをダウンロードするのですが、今回は手軽に環境構築をお試しするためのVagrantfileをサクッと作っておきました。 Vagrant.configure("2") do |config| config.vm.box = "CentOS/7" config.vm.network :private_network, ip: "192.168.33.10" config.vm.provision "docker" end Vagrant.configure("2") do |config|...end で囲まれた範囲が、細かい設定を記述する箇所になります。 config. vm .box は仮想環境のOSを表します。今回は CentOS を使用します。 config. vm .network は仮想環境の IPアドレス の指定に使用します。実はこれがかなり重要で、これが設定されていないと仮に仮想環境上でWebサーバを立ち上げても、 IPアドレス がないのでPC上からアクセスできません。考えてみれば当然のことなのですが…こんな単純なことに3,4日も気づかずつまづいてしまいました… config. vm .provision で、環境の作成時にインストールするソフトを指定します。今回は前述の通りdockerを使用するので、今のうちに記述しておきます。 これだけ書いて保存したら、あとは仮想環境を作成して接続するだけです。 vagrant up vagrant ssh vagrant up でVagratfileを元に仮想環境を起動し、その環境に vagrant ssh で接続します。初回はdockerのインストール等もあるので多少時間がかかりますが、気長に待ちましょう。 しかし、気長といってもここに第二のつまづきポイントがあり、何故かVagrantfileは問題なく作成できているはずなのですが、10分経っても20分経っても起動が完了せず、 タイムアウト してしまうことがあります。 調べたところ、どうやら BIOSの設定 が邪魔をしているらしく、この設定をこちょこちょして何とか解決。 Dockerイメージの取得 接続が完了すると、ごく一般的な CentOS 上で Linux コマンドを叩けるようになります。 この環境上に、Dockerを使ってコンテナを作っていくわけですが、それには主に2つの方法があります。 Vagrantfileを作成したのと同じフォルダ内に「Dockerfile」を作成してビルドする dockerHub という、公式で提供されるコンテナの「カタログ」からDockerfileを借りてくる 細かく設定を行いたい場合は1.で行うのもいいですが、今回はとっかかりなので2.の方法で行きましょう。 プロジェクト管理 OSS である「 redmine 」と、そのデータを格納するための「 MySQL 」を作成してみます。 docker pull sameersbn/redmine:3.3.1 docker pull sameersbn/mysql:latest dockerHubからイメージを借りてくる際は、 docker pull コマンドを使用します。特に細かい設定は必要なく、dockerHubで提供されているイメージ名とバージョンを指定するだけで落とせるので便利。 こちらも時間がかかるので、気長に待ちましょう。 mkdir -p /srv/docker/redmine/mysql mkdir -p /srv/docker/redmine/redmine 続いて、 MySQL と redmine のデータを格納するフォルダを作ります。 本来データはコンテナの中に格納されていますが、このフォルダと紐づけを行う(後述)ことで両者を共有することが出来ます。 四次元ポケット これで、コンテナを動かす準備が完了しました。 実行 少し長いですが、以下2つのコマンドを実行してみてください。 docker run --name=mysql-redmine -d --env='DB_NAME=redmine_production' --env='DB_USER=redmine' --env='DB_PASS=redpass' -v /srv/docker/redmine/mysql:/var/lib/mysql sameersbn/mysql:latest docker run --name=redmine -d -p 8080:80 --link=mysql-redmine:mysql -v /srv/docker/redmine/redmine:/home/redmine/data sameersbn/redmine:3.3.1 docker run コマンドでコンテナを動かしています。以下、コマンドのオプションについて解説。 --name : 起動するコンテナの名前を定義しています。 -d : バックグラウンドで動かします。これがないと、一つ動かしている間は何も操作できなくなってしまいます。 --env : コンテナで扱う 環境変数 を設定します。 -v : コンテナの中にあるデータ配置のためのフォルダを、仮想環境の特定のフォルダと紐づけます。 -p : 起動したコンテナのポート番号と、自分のPC上で操作する時に指定するポート番号を紐づけます。 --link : 他のコンテナを指定することで、そのコンテナと連携することが出来ます。 これでPC側からアクセスができるはずなので、 http://192.168.33.10:8080 にアクセスします。 Redmine 使用者には見慣れたTOPページが表示されました！ おわりに Vagrant とDockerを使って環境を構築するやり方を説明いたしました。 正直なところ、結構噛み砕いて説明したつもりでしたがそれでも大分難しいと思います。 なんとたったこれだけのことを調べ始めてから記事にするまで約一ヶ月 ただ、当然若手エンジニアにとっては勉強になりますし、何より どんな環境でも、同じように環境を構築できる のはとても便利だと思います。ぜひ皆さんも試してみてはいかがでしょうか。 参考 acchi-muite-hoi.hatenablog.com https://qiita.com/hidekuro/items/fc12344d36d996198e96 qiita.com weblabo.oscasierra.net qiita.com www.risewill.co.jp エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com *1 : 以下、これを「コンテナ」と呼びます

はじめまして！普段業務では Java や Swift を書いていますが、本当は(?) PHP が大好きな @kawanamiyuu です。 今日は PHPer な私にとって嬉しいお知らせです！ お知らせ 関西での PHP の一大イベント、 PHP カンファレンス関西に弊社のエンジニアが登壇します。 また、 株式会社ラクス はシルバースポンサーとしてイベントに協賛します。 日時 : 2018 年 7 月 14 日 (土) 会場 : グランフロント大阪 公式 HP : https://2018.kphpug.jp/ 2018.kphpug.jp 登壇内容 タイトル チャットディーラーの高速開発を支える Laravel 概要 「 チャットディーラー 」は 株式会社ラクス が提供する、チャットを活用した Web 接客ツール ( SaaS ) です。 10 年以上 PHP でノン フレームワーク で開発・運用されてきた主力サービス（ メールディーラー ）の開発チームが、新規に姉妹サービス（ チャットディーラー ）を立ち上げる際に Laravel を選択をしました。 開発期間半年というスピードが求められる中で、チームが Laravel に抱いた理想と現実、また、Laravel (Blade) と Vue.js の組み合わせにより発生した 脆弱性 への対応など、Laravel での新規サービス立ち上げの経験を具体的にお伝えします。 最後に 当日は弊社のエンジニア数名もイベント本編および懇親会に参加します。セッションや懇親会を通して、弊社のサービス開発やエンジニアリングについてぜひたくさんお話できればと思います！

こんにちは。開発エンジニアのd_ shr ( id:d_shr )です。 前回はNode.jsのことを書いていましたが、今回は PostgreSQL のことを書きます。 前回投稿した記事 tech-blog.rakus.co.jp はじめに PostgreSQL10 変更点 ロジカルレプリケーション PostgreSQL9.6までのレプリケーション PostgreSQL10 ロジカルレプリケーション 所感 パーティショニング これまでのパーティショニング 宣言的テーブルパーティショニング 所感 パラレルクエリの強化 PostgreSQL9.6で対応していたもの PostgreSQL10で追加されたもの 所感 その他 まとめ 参考 はじめに 最近、 PostgreSQL について調査する機会がありました。 主にPostgreSQL9系やPostgreSQL10の変更点を調査しましたが、その中でも最新のPostgreSQL10について書きます。 PostgreSQL10はリリースから半年以上経っており今更ですが、新機能や変更点で気になったものをピックアップしてまとめようと思います。 PostgreSQL10 変更点 ロジカル レプリケーション 宣言的テーブルパーティショニング 改善された並列問い合わせ その他 ロジカル レプリケーション PostgreSQL10でPublish/Subscribeによる論理 レプリケーション が実装されました。 PostgreSQL9.6までの レプリケーション マスタからスタンバイに トランザクション ログを転送し適用することでデータの複製を実現していました。 対象はデータベース全体。完全な複製でスタンバイには物理的な変更はできないものでした。 PostgreSQL10 ロジカル レプリケーション レプリケーション 先に対して変更した レプリケーション 情報を送付できるようになります。 トランザクション ログを「テーブルに〇〇を挿入しました」のように論理的な変更内容として転送することができます。 データベース全体を レプリケーション するのではなく、特定のテーブルの情報やinsertだけを レプリケーション することが可能です。 レプリケーション 情報のやりとりにPublish/Subscribe(出版/購読型)モデルのメッセージ送信を用いています。 複製元でPUBLICATIONを作成し、複製先でSUBSCRIPTIONを作成することでテーブルの同期と レプリケーション が行われます。 INSERT, DELETE, UPDATEには対応していますが、CREATE TABLEなどには対応してません。 所感 柔軟に レプリケーション できるようになったという印象を受けました。 学生の頃にPub/Subモデルのメッセージングを用いた開発をしていたので興味深い内容でした。 パーティショニング パーティショニングとは、巨大な親テーブルを複 数の子 テーブルに分割することです。 今までパーティショニングの手順がめんどうだったのですが、CREATE TABLE文でパーティショニングが構築可能になりました。 これまでのパーティショニング 親テーブルを作成 親テーブルを継承する子テーブルを作成 CHECK制約を作成 親テーブルにINSERTトリガを作成 ...... 宣言的テーブルパーティショニング CREATE TABLE文で構築可能 1. 親テーブル作成 PARTITION BY構文 2. 子テーブル作成 PARTITION OF構文 所感 PostgreSQL9.5でもUPSERTが追加されていましたが便利な構文が増えたということで使ってみようかなと思いました。 パラレルクエリの強化 パラレルクエリとは、PostgreSQL9.6で追加された大きなテーブルに対するクエリを並列問合せで実行することです。 パフォーマンスの向上が期待できます。 PostgreSQL9.6で追加されたパラレルクエリ(並列問い合せ)がPostgreSQL10で強化されています。 PostgreSQL9.6で対応していたもの シーケンシャルスキャン 結合(nested loop, hash join) 集約 PostgreSQL10で追加されたもの インデックススキャン(B-tree, index only scan, bitmap heap scan) 結合（merge) 非相関副問合せ 所感 パラレルクエリ自体、バージョンアップで既存のシステムに取り入れるのは難しいのかなという印象を持っています。 これからも並列化はどんどん強化されそうな流れなので、パフォーマンス向上に繋がるなら考慮するべきなのかなと思います。 正しく理解しておきたい機能だと思いました。 その他 PostgreSQL10.3の修正で 他ユーザからの search_path を使った「 トロイの木馬 」攻撃を防御する PostgreSQL とアプリケーションの設定方法がドキュメントに記載されました。 pg_dump や他のクライアントプログラムで安全でない search_path 設定の使用が回避されました。 *1 PostgreSQL のpublic スキーマ の仕様によるもので、悪意あるユーザがpublic スキーマ に不正な挙動を行うユーザー関数を仕込んでおくことができます。 他のユーザがその不正なユーザ関数を一般のユーザ関数として実行させることで攻撃（漏えい、改ざんなど）ができてしまう問題がありました。 「 pg_dump 」「pg_upgrade」「vacuumdb」などの管理者ユーザで実行されるアプリケーション関してはsearch_pathからpublic スキーマ が取り除かれました。 PostgreSQL の仕様が原因になっていることなのでpublic スキーマ の設定を見直す必要もあり 既存のシステムで問題に直面しそうな場合は、運用面のことを考えるのなかなか辛いなという印象を受けました。 まとめ PostgreSQL10についてまとめました。 個人的に興味深い技術が使われていたものや、構文が追加され便利になったものなどありました。 また、パフォーマンスの向上に繋がることや 脆弱性 に関連した修正もあり、正しく理解しておかないといけないこともあるなと思いました。 参考 PostgreSQL 技術情報 - SRA OSS, Inc. 日本支社 PostgreSQLの“仕様”による、運用者にとって悩み深い脆弱性とは：OSS脆弱性ウォッチ（6） - ＠IT *1 : PostgreSQL 10.3 に関する技術情報 - SRA OSS, Inc. 日本支社

はじめに 前回実装した処理 今回実装した処理 利用したAPI Androidのバージョンに伴う注意点 実装概要 実装例 おわりに はじめに kuwa_38です。以前 Android Studio を使ってみたので、その続きとして天気情報を表示するアプリを実装してみました。簡単に実装できるかと思いきや、 Android では API 接続に非同期処理( AsyncTask )を用いる必要があるらしく苦戦しました。この記事では今回苦戦した非同期処理も含め、天気情報を表示するアプリについて、実装に必要なこと、実装したコードを記載します。 前回実装した処理 今回は下記の実装に付け加える形で実装したため記載しておきます。 Android Studioを使ってHello Worldをやってみた 初期画面の表示 ボタンを押すとテキストが変わる 今回実装した処理 ボタンを押すとその日の大阪の天気が表示される 利用した API Weather Hacks を利用させて頂きました。GETでエンドポイントにアクセスすることで、パラメータ city で設定した都市の天気を JSON で返してくれます(因みに 270000 は大阪です)。 補足： jqを活用してAPIレスポンス等から欲しい情報だけを抽出する【初級編】 $ curl -s http://weather.livedoor.com/forecast/webservice/json/v1\?city\=270000 | jq -r # 結果 { "pinpointLocations": [ { "link": "http://weather.livedoor.com/area/forecast/2710000", "name": "大阪市" }, # ...(中略) "link": "http://weather.livedoor.com/area/forecast/270000", "forecasts": [ { "dateLabel": "今日", "telop": "晴れ", "date": "2018-05-27", "temperature": { "min": null, "max": { "celsius": "29", "fahrenheit": "84.2" } }, Android のバージョンに伴う注意点 それでは実装、といきたいところですが、先に私がハマった注意点について述べておきます。 メインスレッドではネットへ接続する処理ができない 行おうとすると android.os.NetworkOnMainThreadException が発生します 参考： 【Android】メインスレッド(要は画面処理)でhttpリクエスト投げようとしたら怒られた。　〜NetworkOnMainThreadException〜 HttpClientが使えない 参考： Android 6.0でApache HTTP Clientが削除されました。 実装概要 コードなどは次の節に記述します。この節では実装すべきことについて大まかに述べます。 ※ 今回は実機デバックを対象とします( エミュレータ を使用する場合は、 エミュレータ の wifi 設定などが必要です)。 ネット接続を許可する AndroidManifest.xml に下記を追記 <!-- ネット接続を許可する --> <uses-permission android : name = "android.permission.INTERNET" /> ボタンを押すと特定の処理を実行する 前回の記事を参照ください API サーバに接続する 注意で述べたようにメインスレッドでは接続できませんので、実行用のクラスを作成してあげます 参考： AsyncTaskを使った非同期処理のきほん AsyncTask を継承するクラス(今回は AsyncHttpRequest というクラス名にしました)を作成する 作成したクラス内に doInBackground (非同期で行いたい処理を記述する)メソッドを実装する メインスレッド( MainActivity.java )で1のクラスを インスタンス 化し、 execute メソッドを呼び出す → doInBackground が呼び出される 受け取った JSON を加工する 受け取った文字列をJSONObjectでパースし、天気情報を取り出します 天気情報を表示する AsyncTask を継承するクラスで onPostExecute (非同期処理が終わった後に実行される)メソッドを実装し、メインスレッドのラベルを変更する 実装例 下記に MainActivity.java 、 AsyncHttpRequest.java ( AsyncTask を継承するクラス)を載せますので、実装してみたい方は参考にして下さい。 ※ AndroidManifest.xml は1行追記したのみですので載せていません MainActivity.java import android.support.v7.app.AppCompatActivity; import android.os.Bundle; import android.view.View; import java.net.MalformedURLException; import java.net.URL; /** * トップ画面を制御するActivityクラス. */ public class MainActivity extends AppCompatActivity { /** * 画面を表示する. * note:デフォルトで実装されている * @param savedInstanceState savedInstanceState */ @Override protected void onCreate(Bundle savedInstanceState) { super .onCreate(savedInstanceState); setContentView(R.layout.activity_main); } /** * テキストラベルを変更する. * @param view view */ public void changeTextView(View view) { // 非同期処理(AsyncHttpRequest#doInBackground())を呼び出す try { new AsyncHttpRequest( this ).execute( new URL( "http://weather.livedoor.com/forecast/webservice/json/v1?city=270000" )); } catch (MalformedURLException e) { e.printStackTrace(); } } } AsyncHttpRequest import android.app.Activity; import android.os.AsyncTask; import android.widget.TextView; import org.json.JSONException; import org.json.JSONObject; import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; import java.io.InputStreamReader; import java.net.HttpURLConnection; import java.net.URL; /** * 非同期処理を行うクラス. */ public final class AsyncHttpRequest extends AsyncTask<URL, Void, String> { private int TODAY_FORCAST_INDEX = 0 ; private Activity mainActivity; public AsyncHttpRequest(Activity activity) { // 呼び出し元のアクティビティ this .mainActivity = activity; } /** * 非同期処理で天気情報を取得する. * @param urls 接続先のURL * @return 取得した天気情報 */ @Override protected String doInBackground(URL ... urls) { final URL url = urls[ 0 ]; HttpURLConnection con = null ; try { con = (HttpURLConnection) url.openConnection(); con.setRequestMethod( "GET" ); // リダイレクトを自動で許可しない設定 con.setInstanceFollowRedirects( false ); con.connect(); final int statusCode = con.getResponseCode(); if (statusCode != HttpURLConnection.HTTP_OK) { System.err.println( "正常に接続できていません。statusCode:" + statusCode); return null ; } // レスポンス(JSON文字列)を読み込む準備 final InputStream in = con.getInputStream(); String encoding = con.getContentEncoding(); if ( null == encoding){ encoding = "UTF-8" ; } final InputStreamReader inReader = new InputStreamReader(in, encoding); final BufferedReader bufReader = new BufferedReader(inReader); StringBuilder response = new StringBuilder(); String line = null ; // 1行ずつ読み込む while ((line = bufReader.readLine()) != null ) { response.append(line); } bufReader.close(); inReader.close(); in.close(); // 受け取ったJSON文字列をパース JSONObject jsonObject = new JSONObject(response.toString()); JSONObject todayForcasts = jsonObject.getJSONArray( "forecasts" ).getJSONObject(TODAY_FORCAST_INDEX); return todayForcasts.getString( "dateLabel" ) + "の天気は " + todayForcasts.getString( "telop" ); } catch (IOException e) { e.printStackTrace(); return null ; } catch (JSONException e) { e.printStackTrace(); return null ; } finally { if (con != null ) { con.disconnect(); } } } /** * 非同期処理が終わった後の処理. * @param result 非同期処理の結果得られる文字列 */ @Override protected void onPostExecute(String result) { TextView tv = mainActivity.findViewById(R.id.messageTextView); tv.setText(result); } } おわりに 本記事では Android Studio を使い、天気情報を表示する Android アプリの実装方法を紹介しました。まだまだ実用には遠いクオリティですが、非同期処理やjqコマンドなど知らなかったことを学ぶいい機会になりました。自分の学習目的で始めた部分が大きいですが、 Android アプリ開発 の初心者や非同期処理の実装で困っている方の手助けになれば幸いです。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 rakus.hubspotpagebuilder.com ラク スDevelopers登録フォーム https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/ イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ ◆TECH PLAY techplay.jp ◆connpass rakus.connpass.com

はじめに こんにちは、 id:FM_Harmony です。 Rakus Developers Blogでは5回目の投稿です。 前回の記事はこちら↓ tech-blog.rakus.co.jp 今回も前回と同じくビアバッシュの補足ネタです。（ビアバッシュ...?という方は コチラ ） テーマは「Mattermost」についてです。 はじめに Mattermostとは？ Mattermost Serverの構築 事前準備 データベースの準備 Mattermost Serverの構築 Mattermostを触ってみる Mattermostの初期設定 Webhookを使ってみる おわりに 参考 Mattermostとは？ MattermostとはSlackに似た オープンソース のチャットツールです。 大きな違いはSlackが クラウド 型のサービスであるのに対し、 Mattermostはオンプレミス型 のサービスであることです。 そのため、社内情報を外部に保存したくないという理由で、チャットツールとしてSlackではなくMattermostを選ぶこともあるようです。 ↑Mattermostの公式ページにもSlackとの違いが説明されています。 今回はそんなMattermostのサーバを構築して色々お試ししてみた話です。 Mattermost Serverの構築 それではMattermost Serverの構築について説明します。今回は CentOS7.1 へ Mattermost Server v4.4.0 のサーバを構築しました。 また、データベースサーバとMattermost Serverは同一のマシンに構築します。 構築時の手順は参考リンク内の Installing Mattermost on RHEL 7.1 を参考にしました。 なお、今回の手順はあくまで手元での検証を目的としたものであるため、セキュリティ等の考慮を省いている部分もあります。 そのため、 本番構築時には手順をそのまま適用すべきではない ことにご注意ください。 事前準備 事前にパッケージは最新のものにします。 [hoge@huga ~ ]$ yum update データベースの準備 Mattermostではユーザや投稿を保存するデータベースとして、 PostgreSQL か MySQL を使うことができますが、今回は PostgreSQL v9.4を利用します。 また、 PostgreSQL サーバの構築および初期化は完了しているものとします。 まず、利用するデータベースを作成します。(postgresユーザは PostgreSQL の初期化時に作成されているはずです) [hoge@huga ~]$ psql -U postgres postgres=# CREATE DATABASE mattermost; 次に作成したデータベースをMattermostが使うためのユーザを作成し、 mattermost データベースに関する全ての権限を与えます。 （ユーザのパスワードは適当に決めてください） postgres=# CREATE USER mmuser WITH PASSWORD 'xxxx'; postgres=# GRANT ALL PRIVILEGES ON DATABASE mattermost to mmuser; postgres=# ¥q 最後に postgreSQL の接続設定を変更します。 postgresql.conf を編集して listen_addresses を全アドレスに、 pg_hba.conf を編集して localhost から接続する際の認証方式を trust にすれば基本的には問題ないはずです。 Mattermost Serverの構築 では、いよいよMattermost Serverを構築します。 とりあえず、 /usr/local/src 直下にインストールしたいバージョン（今回はv4.4.0）のMattermost Serverをダウンロードします。 [hoge@huga ~ ]$ cd /usr/local/src [hoge@huga src ]$ wget https://releases.mattermost.com/4.4.0/mattermost-4.4.0-linux-amd64.tar.gz 次に、ダウンロードしたファイルを解凍し、 /opt 直下に配置します。 その後、配置した ディレクト リの直下に data ディレクト リを作成します。 [hoge@huga src ]$ tar -xvzf mattermost-4.4.0-linux-amd64.tar.gz [hoge@huga src ]$ sudo mv mattermost /opt [hoge@huga src ]$ sudo mkdir /opt/mattermost/data そして、Mattermostを管理するためのシステムユーザを作成し、先ほど配置した mattermost ディレクト リ以下のファイル・ ディレクト リをシステムユーザが書き込み可能にします。 [hoge@huga src ]$ sudo useradd --system --user-group mattermost [hoge@huga src ]$ sudo chown -R mattermost:mattermost /opt/mattermost [hoge@huga src ]$ sudo chmod -R g+w /opt/mattermost 最後にMattermostがデータベースと接続する際の設定を行えば主な作業は完了です。 /opt/mattermost/config/config.json を以下のように編集します。 "DriverName" を postgres とする。 "DataSource" を "postgres://mmuser:(mmuserのパスワード)@localhost:5432/mattermost?sslmode=disable&connect_timeout=10" とする。 ここまで完了すればMattermostを起動することができるはずです。 以下のコマンドからテスト起動を行えます。 [hoge@huga src ]$ cd /opt/mattermost [hoge@huga src ]$ sudo -u mattermost ./bin/platform 起動に失敗する場合は手順を見直してみてください。 また、本来はMattermost Serverをサービス化した方がMattermostを起動する際に便利なのですが、今回は割愛させていただきます。 Mattermostを触ってみる Mattermostの初期設定 初期設定を変更しない場合、先ほどテスト実行したMattermost Serverは8065ポートでアクセスを待ち受けます。 8065ポートへアクセスすると、下記のような管理者の設定画面が表示されるかと思います。 管理者の設定を終えると チーム を選択する画面に移ります。 Mattermostでは チャンネル と呼ばれるチャットが集まって、チームを成しています。 初期状態ではチームはありませんので、 Create a new team をクリックしてチームを作成します。 作成すると以下のような画面に移りますが、これがMattermostのチャット画面です。 tutorialは適当に飛ばしてください。 Webhookを使ってみる Mattermostは Webhook を利用することで外部と連携することができます。 まずはMattermostがWebhookを利用できるか設定を確認するために、チャット画面左上のメインメニューから System Console に移動します。 次に、 System Console 内の INTEGRATINS > Custom Integrations を選択します。 すると、 Enable Incoming Webhooks , Enable Outgoing Webhooks , Enable Custom Slash Commands というオプションがあるかと思います。 初期設定ではいずれも true のはずなので、今回はそのままにします。 ↑System Console画面、今回は赤枠で囲った部分をすべて true にします。 画面左上のメインメニューから Switch To (チーム名) を選択して、チャット画面へ戻りましょう。 その後、再びメインメニューから今度は Integrations を選択します。 すると、先ほど紹介した3つの外部連携機能の項目が選べるはずです。 今回は例として Incoming Webhook を利用してみましょう。 3つの項目の中から Incoming Webhook を選択します。 その後、表示された画面の右上にある Add Incoming Webhook を選択します。 すると、 Webhook の設定画面に移りますので、それぞれ適当な値を設定して Save を選択します。 設定が完了するとURLが表示されます。 Incoming Webhook ではこのURLに対してリク エス トを送ることで、Mattermostにメッセージを表示することができます。 ↑ Incoming Webhookの設定画面です。 試しに以下のコマンドをターミナルから実行してみます。 curl -i -X POST -d 'payload={"text": "this is sample bot"}' (利用する Incoming WebHooks のURL) すると、以下の画像のように「this is sample bot 」というメッセージが表示されるはずです。 また、設定を変更していない場合、投稿者名に BOT という表示が出ているはずです。 このように Incomming Webhook を利用することで、外部のサービスからMattermostへメッセージの送信を行うことができます。 おわりに いかがでしたでしょうか。 駆け足になってしまいましたが、Mattermost Serverの構築手順とWebhookについて少しでもご理解いただければ幸いです。 Mattermostサーバ構築の難易度はそれほど高くないと思いますので、これからチャットツールを導入したいという方は、この機会にぜひMattermostを体験してみてはいかがでしょうか。 参考 Installing Mattermost on RHEL 7.1 CentOS7系の Linux サーバにMattermost Serverを導入する手順について書かれています。 SlackクローンのMattermostを使ってみる - 外部連携編 -（WebHooks、Hubot） Mattermostで外部連携を行う方法について書かれています。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

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ヶ国で展開している新しい イノベーション とリーダーシップそしてマネジメント運動です。 近年マネジメントの領域で注目されている自己組織化や 心理的 安全性などについても言及されており、 アジャイル 開発の現場でも手法が使われているようです。

こんにちは sts -250rrです。 今回も前回の記事に引き続きAR技術の紹介になります。 tech-blog.rakus.co.jp 前回は簡単にARを体験する。まででしたので今回は Software Design のコラムにあったARアプリARKittenを作ってみました。 gihyo.jp ちなみに Github の リポジトリ でサンプルを公開してくださっていますので、こちらでまず試してみるのも良いかもですね。 では、やっていきましょう。 猫、ARに立つ カメラを向かぬ猫 まとめ 実録ビルドできない事件簿 猫、ARに立つ 前回はARの世界で平面を検出し、キューブを設置するところまででしたが、それではあまりに味気ないので猫を配置することにします。 ※AssetStoreからARKitをインポートする部分は割愛します。 UnityのAssetStoreでは、3Dのモデルデータを購入することもできます。 ここから猫のモデルを取得していきたいところですが、残念なことにARKittenで使用する猫のモデルは作成者の諸事情により、AssetStoreからダウンロードできなくなってしまいました。 現在は上記の Github からモデルデータを取得してくるしかないようです。 Kitten ディレクト リを プロジェクト名/Assets 配下に格納しておきましょう。 単純に猫を平面に追加するだけでは、拡張現実らしくなりません。 それはなぜか、ズバリ 影がないから です。 そこで今回作成するアプリでは UnityARShadows というサンプルを元に作成していきます。 このサンプルであれば平面を検出した部分に3Dモデルの影を落とすことができます。 UnityARShadows には Cube の代わりに HitPlayer が存在しています。 これを Assets/Kitten/Prefabs/KittenNPC に置き換えます。 これだけでは iOS の画面をタップしても猫が平面に配置できないので スクリプト を組み込んでいきます。 KittenNPC を選択しインスペクターウィンドウ（右側に表示されている設定窓）の設定を以下のようにします。 ここで一度ビルドして、画面をタップして見て猫を配置してみます。 猫に影がついていたり、アニメーションが定義されているので、まるで猫がそこにいるようです。 カメラを向かぬ猫 単純に猫を配置するだけでは、場所によってはそっぽを向かれてしまいます。 猫を配置した時にいつもこちら側（カメラ）を向いてくれるように しつけ スクリプト を追加していきます。 ここでは猫がカメラを向いてくれる時の処理の流れを解説します。 猫位置の取得 タップで配置した猫の位置を取得します。 このままでは猫は初期の向きを向いてしまいます。 3Dグラフィックスの世界では向き（回転）という情報は クオータニオン と呼ばれるもので保持されています。 カメラ位置の取得 猫とカメラの位置（座標）を比較することで、猫がどの方向を向けば良いのかがわかるようになります。 カメラの方に向かせる 猫とカメラの位置の差から、猫がどれだけ回転すれば良いのかを計算します。 この計算は3Dを扱うライブラリであれば、大抵3次元ベクトルを与えてやれば計算してくれる関数があります。 ARKitであれば、 Quaternion クラスの LookRotation クラスがその一つに該当します。 ※ スクリプト の内容はサンプルコードを眺めてみてください。 スクリプト が完成したら再びビルドしましょう。 そこには従順にこちらを向いている猫が佇んでいるはずです。 まとめ 今回は前回ご紹介したARKitのサンプルプログラムを作ってみました。 猫が配置され、それを眺めるまでしかできませんが、本来そこにいないはずの猫が画面を通して存在している感覚はまさしく 拡張現実 です。 次回も引き続きARKitネタをお送りしたいと思います。 お楽しみに、 実録ビルドできない事件簿 iPhone の iOS をアップデートしたばかりにビルドできなくなってしまった・・・・ エラー内容を見てみると、 「iOS11.3のデ バイス サポートファイルがない」ということだそうです。 みなさん結構起きてしまっているようで、解決策を調べてみたらすぐに出てきました。 今回は以下の記事を参考にさせていただきました。 iOSをアップデートしたために実機でビルドができない - Qiita

ラク スのメールディーラーの開発を行っている@nerobluebrosです。 5月9日にメールディーラーのバージョン12.2をリリースしました。 今回はそのメールディーラーバージョン12.2とリリースについての紹介をします。 バージョン12.2では33の機能と修正をリリース リリースは複数回に分割して実施 おまけ バージョン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/

こんにちは。エンジニアのmickey-STRANGEです。 前回は めんどくさがりによるめんどくさがりのためのスマホアプリ開発についてお話したいと思います。 なんて言いながら、全てをJSでごりっと無理やり解決する方法をご紹介しました。 tech-blog.rakus.co.jp はい、タイトル詐欺です、すみません。冷静に考えて、この作りのWebページが世の中にない現状、これよりも簡単な方法が必ずあるはずなんですよね （当時サンプル書きながらコレめんどくさいな、なんて思ってないです） 。 今回はタイトル詐欺ではなく、Herokuというサービスを用いてWeb アプリ開発 の環境構築が本当に簡単に出来てしまう方法をご紹介いたします。 Heroku（へろく）とは Herokuで環境構築 php+postgresアプリの作成 デプロイソースの指定 ブラウザからアクセス！ 【補足】phpからpostgresの接続 終わりに 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 1 で使った フレームワーク ってなんだっけ。ら……ららばい？」 坂田 「Laravel。 PHP のWebアプリケーション フレームワーク だね。あと JavaScript でVue.js」 何言ってるの？ みたいな顔をしつつも坂田くんはちゃんと答えてくれます。ありがたや。 ペン未 「そうでした。使ってみてどうだった？ 例えばMD 2 と比べてみて」 MDはCDと同じく PHP で書かれていますが、特に フレームワーク は使用していないということは以前坂田くんから聞いていました。 坂田 「 フレームワーク があるとやっぱりかなり楽。面倒なことはやってくれてるし、どこにどんなことを書くといいのかが明確に分かれてるから、作りたい機能のことに集中できる。これはLaravelに限った話じゃないとは思うけど。他に フレームワーク を触ったことが無いから他の フレームワーク と比べてってなるとよくわからない」 ペン未 「Vue.jsは非難殺到だったって話だったよね」 坂田 「あー、うん、慣れるまではちょっと大変だったかな。それまで慣れ親しんだ手続き的なJSの書き方とは パラダイム が違うというか。Vue.jsっぽい書き方ってどんなだろうってはなった。開発入る前にもちょっとは勉強してたけど、実装始めてからも公式サイトのドキュメント読んでることが最初のうちは多かった」 ペン未 「へー……。先輩に教える場面もあったって記事には書いてあったよね」 坂田 「みんなして慣れてなかったからね。LaravelもVue.jsも。何か新しくわかったことがあったらけっこう教えあってた。Laravelだとこう書けばいいみたいですよー、とか、Vue.jsでこう書くとそれたぶんうまくいきます、とか」 話しているうちにオフィス近くの定食屋さんに到着し、食券を購入するために話は一時中断となりました。 かみせん ペン未 「そういえばCDは全社交流会 3 で表彰されてましたよね」 坂田 「そうですね」 ペン未 「そういえばあなたもういっこ表彰されてませんでしたっけ。なんででしたっけ」 坂田 「そうですね。かみせんプロジェクトですね」 ペン未 「それ前から思ってたんだけど、かみせんって結局なにしてるの」 坂田 「目標は、なんだっけ……新しい技術とかにチャレンジして、わかったことを普段の業務の改善に活かすこと。具体的にはQCポータル 4 の段階的マイクロサービス化を今やってるとこで、私はマイクロサービス一つの実装をやってた」 Haskell ……？ ペン未 「それで Haskell ？」 坂田 「そうね」 ペン未 「なんで Haskell ？」 坂田 「え、なんかかっこいいから……純粋関数でプログラム書くのってなんか良さそうじゃない？　変なところに副作用が出ないから修正のための影響範囲の調査だって楽そうだし、もし影響があるなら型検査で引っかかるだろうからすぐわかるし」 ペン未 「でもそれでアプリケーション作るとかイメージできないんだけど」 坂田 「それはライブラリがあるから大丈夫。この前ビアバッシュ 5 で紹介した本 6 にはWebアプリケーションを作る章もあるし簡単な API サーバーくらいならすぐに」 ペン未 「っと、そろそろ時間やね。行きましょうか」 そして仕事はつづく Haskell について熱く語ってもらえそうな感じになっていましたがあいにくと時間切れ。ごちそうさまと告げて店を出、そのあとは他愛もない話をしつつオフィスに戻りました。午後の業務が始まります。 自席について先ほどの話の内容をメモしつつ、私が思ったのは一つでした。 Haskell 好き、増えるといいね…… Chat Dealer（チャットディーラー）の略称。CDについて詳しいことは商品サイトを参照 → https://www.chatdealer.jp ↩ Mail Dealer（メールディーラー）の略称。MDについても詳しいことは商品サイトを参照 → https://www.maildealer.jp ↩ 年度末に開催される全社員が集まってのパーティ。その年度に特に活躍したりした個人・グループが表彰されたりする。 ↩ 社内用システムのひとつ。いくつか機能はあるが、もっぱらその日の仕事はどんなことを何時間やったか入力のために利用される ↩ 月1で開催している開発部の交流会。ビールなどのアルコール(+軽食)を片手にフランクに技術内容について発表したり語り合ったりする。このブログ内でも過去に 紹介された 。 ↩ 本間 雅洋, 類地 孝介, 逢坂 時響 (2017)「Haskell入門 関数型プログラミング言語の基礎と実践」技術評論社 ↩

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

はじめに こんにちは。ラクスエンジニアの 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 の返り値を記述してあげれば実行結果を引き継げます。 慣れるととても使いやすく、記述もシンプルになるので、 クロージャ の書き方をぜひマスターしてみてください。

はじめに 新卒3年目に突入しましたnorth_mkyです。 エンジニアをしていると一度はコンピュータでの文字の扱いについて考えることがあるのではないでしょうか。 今回は、かなりの国の文字をカバーしている符号化 文字集合 、 unicode の特徴について書きます。 ※今回はわかりやすさのために厳密性は求めない書き方をしている箇所があります。ご容赦くださいませ。 はじめに 1. unicodeとは 2. unicodeの特徴 特徴1. 4次元で一つの文字を表す 特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字) 特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字) 特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字) 3. unicodeは進化し続けている ~タイトル回収~ 4. 終わりに 5. 参考文献 1. unicode とは 符号化 文字集合 のひとつです。 ...と書くと頭に はてな が浮かぶかもしれません。 文字というのは世界規模だとかなりの数が存在します。 ただ文字を集めただけではまとまり(ひらがな、漢字、ラテンなど)を表現することが難しかったり形や使われ方の違う文字の統一的に管理することが難しいため、「この 位置 にこの文字をおいておく」というように文字を系統的に定義し、管理しやすくしています。この位置のことを 符号位置(コードポイント) といい、字に対して必ず一意の数値で表される符号位置が存在する、つまり字を数値に表せる「符号化」を行っているため、”符号化 文字集合 ”といいます。 unicode の他にも符号化 文字集合 は世界の各地域で存在しています。 こと日本でいいますと文字として、「ひらがな・カタカナ・漢字・アルファベット」を使うため、それらの符号化 文字集合 の定義が必然となります。国内でこれらの文字に特化した有名な符号化 文字集合 は JIS X 0208 があります。 この符号化 文字集合 は単に字を符号位置という位置づけを付与し文字を定義し集めているだけなので、コンピュータで扱いやすい・処理されやすいよう更に特定の アルゴリズム で符号化をしていることが多いです。この符号化の種類のことを 符号化方式 といい、具体的には下記のように符号化 文字集合 を表現する複数の符号化方式が存在します。 符号化 文字集合 符号化方式 unicode UTF-16 , UTF-8 ... JIS X 0208 Shift_jis , EUC -JP, ISO-2022-JP と、少し長くなりました、話を元に戻しますと unicode とは符号化 文字集合 の一つです。 webでは デファクトスタンダード の符号化方式( 文字コード )、 UTF-8 の文字はこの unicode を符号化したものです。冒頭で述べた通り、 unicode は多くの国の文字をカバーしているのですが、それゆえに 文字集合 の表し方や字の定義の仕方に特徴があります。以下にその特徴を述べたいと思います。 2. unicode の特徴 unicode には大きな特徴が4つあります。 特徴1. 4次元で一つの文字を表す 特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字) 特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字) 特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字) 特徴1. 4次元で一つの文字を表す unicode では符号位置は4次元で表しています。 擬似的に表現すると下記のようになります。 characterSet[group(群)][plane(面)][row(区)][cell(点)] = 'あ' unicode では各々の次元をおおよそ1バイト(0x00~0xFF)の範囲で表現しており、1文字を4バイトの符号位置で表現しています。 かなりの符号空間を用意しているわけですが、全世界で現在利用している文字のほとんどはgroup:0x00,plain:0x00の範囲に収まっています。 この範囲だけ特別に BMP (Basic Multiligual plane: 基本多言語面 )というように呼ばれています。 unicode エス ケープ表記で表されている文字で「 u\3042 」というように2バイト表記されているものは、 BMP に属しています。 「 u\3042 」=「group0x00/plane0x00の面にある、row0x30のcell0x42の符号位置」 ちなみに BMP にのれず、別のplaneにある文字として日本で使われている一部の漢字があります。 このplaneの文字を実装していないシステムだと文字がただしく表示されない事象が発生します。 文字があるはずの場所が空白 □の中に×が表示されている文字になる 特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字) unicode では複数の合成用文字( 結合文字 )を合成して1文字を表す、というのを実現可能にしています。 たとえば日本語の「ぱ」などの半濁音は合成用の半濁点が unicode に存在するので、「は」+「 半濁点」で表現できます。(※他の符号化 文字集合 との変換性を考慮して合成用でない半濁点、そもそも「ぱ」だけで符号位置もあります、むずかしいですね...) ですので、たとえば「あ」に半濁点をつけるなど、文字として認識されていない文字を合成して1文字のすることが unicode を用いれば可能になります。 特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字) 漢字を用いる民族、として日本の他に中国・韓国・台湾がなどがありますが、同じ漢字の形で少し書き方が違うものが数多く存在します。(ex. 海|海) このような漢字は unicode では一つの字体に統合しています(統合文字)。 特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字) 特徴3で字体を統合している、といったものの、厄介な問題があります。 別の符号化方式では区別している文字らを unicode に変換すると、その字体の違いが吸収され、もとの符号化方式での字体を再現することができない事象がおこります。 このような事象を解消するために他の符号化方式との互換性を目的として文字が追加されることがあります。追加したそれらは別途 互換文字 と呼ばれます。 3. unicode は進化し続けている ~タイトル回収~ ざっくり unicode について特徴を述べたのですが、やはり「すべての文字を網羅する」のは非常に難しく、既存の符号化 文字集合 との互換性の対応は不可欠となっているようです。ですので、 unicode も進化していっています。最近は文字だけでなく、絵文字の追加も盛んに行われています。それに対してシステムが使っている unicode のバージョンが異なると文字が表示されない現象がおこります。 タイトルに書いた顔文字ですが、まさしく特徴でお話した 結合文字 を駆使して作られています。 私の環境ですと、 chrome では一部文字が表示できませんでしたが、 safari ではきちんと文字が表示されました。 chrome safari 4. 終わりに unicode のざっくりした特徴を述べました。 何気なく単語として聞いている unicode がどんなものなのか、掴めるようになりましたら幸いです。 5. 参考文献 「 文字コード 技術入門」　 http://amzn.asia/0fEbLWi 今回の記事はこちらをとても参考にさせていただきました。 「第三水準漢字」「 サロゲート ペア」などの単語がどのカテゴリのどこに位置する話なのか、などがわかるかと思います。 エンジニア 中途採用 サイト ラク スでは、エンジニア・デザイナーの 中途採用 を積極的に行っております！ ご興味ありましたら是非ご確認をお願いします。 https://career-recruit.rakus.co.jp/career_engineer/ カジュアル面談お申込みフォーム どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。 以下フォームよりお申込みください。 forms.gle イベント情報 会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com

id:radiocat です。 スクラム マスターをやっています。 先月、社内のTechイベントの全社MeetUpで発表してきました。今回はその内容についてあとがき的にまとめてみました。 終わらない スクラム 私達のチームでは、以前このブログでも紹介されている スクラム ト レーニン グを受講して スクラム 開発を実践しはじめました。 tech-blog.rakus.co.jp その経験を踏まえて得た知見や気づきを元に発表したのがこのスライドです。 speakerdeck.com 事前にト レーニン グを積んでいたものの、実際に スクラム を実践してみるとうまくいかない事がたくさん出てきて スクラム イベントが思った通りに終わらない事態に陥りました。そんな状況を改善するために スクラム コーチの吉羽さんにアド バイス を頂いたり、 スクラム ガイドや様々な書籍・資料を参考にして、 スクラム イベントをきちんと終わらせるように取り組んだのが次のような内容です。 タスクの細分化 スクラム ガイドには 作業の単位は1日以下 と書かれています。タスクの粒度が大きいと着手中の状態が長くなり、どの程度進んでいるのか、どれくらいで終わるのかの見通しがわかりづらくなります。そもそも見積もった時点で1日以上かかるということは細かい作業内容が充分イメージできていない事が多いため予定通り進まないことも多くなります。私達のチームでは見積もりが大きい場合は半日以下になるまでタスクを分解するルールにしました。 リファインメントの徹底 開発チームとプロダクトオーナーがしっかり会話してプロダクト バックログ の内容を相互に理解しておかないと、何をどうやって実現するかが明確にならず半日以下のタスクに分解することも難しくなります。 スクラム ガイドに もリフ ァインメントは プロダクトオーナーと開発チームが協力して行う継続的なプロセス であると定義されています。私達のチームでは リファインメント会議を毎週1回定期開催 するルールにしました。 デイリー スクラム の改善 私達のチームでは スクラム で開発を始める前から朝会で全員の進捗を確認していましたが、改めて スクラム で定義されているデイリー スクラム の目的は何かを考えて朝会のあり方を見直しました。 スクラム ガイドには 自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握 するためのイベントと定義されています。そのためチームのリーダーが進行して進捗を確認するスタイルから開発チームが交代制で進行するルールに変更しました。 カンバンを検査の拠り所に カンバンも スクラム で開発を始める前から導入していましたが、チームで意見を出し合って少しずつマイナーチェンジを繰り返しています。デイリー スクラム を毎朝カンバンの前で行うため、カンバンもデイリー スクラム の目的に沿っていることが重要です。チームの状態を検査し今後の状態が予測できる場にするためにより良い使い方を模索してきました。現在、私達のチームが実践しているスタイルは左からToDo、実行中、レビュー中、完了の順にレーンをわけて、優先度の高いタスクを上から順に並べています。右上にいくほどチームとして最も優先度の高いタスクであり、全員で協力して早く終わらせるようにしています。 むきなおりでチームの方向性を再確認 はじめからチームの進むべき方向性がきっちり定まっていて全員の認識が一致しているようなチームは稀です。私達のチームもはじめは手探り状態でどこかで不安を抱えながらスプリントを進めていたため、3回目のスプリントが終わった時に改めてチームの進むべき方向性を議論して目指すべき設計の方針や品質目標を再確認しました。 インペディメントの除去 スクラム ガイドには スクラム マスターは サーバントリーダー であり 、 メンバーが成果を上げるために支援や奉仕をするリーダー であると書かれています。 スクラム にかぎらずソフトウェア開発において開発チームには様々な妨害要素が待ち受けています。近年のソフトウェア開発では、今まで使ったことのない新しい技術や外部のサービスを使うことも当たり前となっています。 スクラム マスターはそのような要素を妨害リストとして洗い出し、それらを少しだけ先回りしたり、問題が小さいうちに手を打つことでチームが成果を上げられるように支援に徹しました。 2つの気づき これらの取り組みを実践することで得た気づきは大きく2つです。 アジャイル 開発のプ ラク ティスは従来型の開発でも役に立つ スクラム 開発で取り組んだことは従来型の開発にも活かせることが多いと気づきました。実際にこのような手法は、従来型の 開発プロセス の中に アジャイル 開発のプ ラク ティスを取り入れるということでハイブリッド アジャイル と呼ばれて実践されているようです。つい最近、日経SYSTEMSの最新号でもハイブリッド アジャイル をテーマにした連載が始まっています。 tech.nikkeibp.co.jp 改善の機会は スクラム 開発のほうが豊富 スクラム 開発では決まったタイムボックスでイテレーティブに開発を進めることによって アジャイル 開発のプ ラク ティスを取り入れるための検査・適応の機会がたくさん訪れます。 アジャイル 開発のプ ラク ティスを実践して改善する機会は スクラム のほうが豊富にあると感じました。 終わらない学びと実践 スクラム 開発でもそれ以外の 開発プロセス でも、 アジャイル 開発のプ ラク ティスは活用できます。そして、 スクラム で開発する機会が訪れた時には アジャイル 開発のプ ラク ティスを活用する機会は増加します。つまり、いずれにしても アジャイル 開発のプ ラク ティスを取り入れて学びと実践を繰り返していくことがチームが成長していくための道筋の１つだと スクラム 開発を通して学びました。スライドではそのような アジャイル 開発のプ ラク ティスを取り入れるための情報源を幾つか紹介しています。 スクラム ガイドによると スクラム 開発は 理解は容易 で 習得は困難 とあります。私達もまだまだ終わりは見えていませんが、習得に向けて学びと実践を繰り返すことでチームがさらに成長できると思っています。

はじめに 2年目のエンジニアになりました、FM_Harmonyです。 Rakus Developers Blogでは4回目の投稿です。 ↓前回の記事はこちら tech-blog.rakus.co.jp さて、弊社ではビアバッシュというイベントを行っています。（ビアバッシュ・・・?という方は コチラ ） 今回はその際に私が発表したことについて、補足も踏まえつつまとめたいと思います。 テーマは tigでcommitをきれいに！ です。 はじめに tigとは？ 準備 tigのインストール（windowsの場合） tigのインストール（macOSの場合） commitをきれいにする理由 使ってみる 実演の前準備 機能を追加して、まとめてcommitする git rebase -i で、commitの分割を始める tigを使ってcommitを分割する - その1 tigを使ってcommitを分割する - その2 tigを使ってcommitを分割する - その3 まとめ 参考資料 tigとは？ Tig is an ncurses-based text-mode interface for git. --- https://github.com/jonas/tig より tigとはターミナル上で動作するgit リポジトリ のブラウザ・・・と言えます。 logの閲覧や、commit操作などを簡単に行うことができる便利なツールです。 動作も高速なので、慣れてしまえばストレスなくcommit操作を行うことができます。 準備 今回は windows で実演を行いますが、 mac でのインストール方法も記載しておきます。 tigのインストール（ windows の場合） Git for Windows の v2.14.2 から、tigが付属するようになりました。 なので、 windows ではtigを特別にインストールする必要はありません。 tigのインストール（ macOS の場合） Homebrew を使うことで簡単にインストールすることができます *1 。 tigを macOS にインストールするためには、ターミナルから以下のコマンドを実行します。 $ brew install tig commitをきれいにする理由 実演の前に、commitを分割する理由を説明します。 開発を行っていると、どうしても commit が大きくなったり、適切に commit が分けられていないという状況に出くわすと思います。 このcommitをそのままにすると何が良くないのかというと、 レビュワーがpushされたcommit一つ一つについて規模を把握しづらい。 後から変更に問題があることが発覚した際に、問題が発生した commitを追いづらくなる. といった事が挙げられます。 なので、上記の問題が発生しないように commitを適切な大きさに分割するとよいです。 その際に、tigを利用すると高速かつ簡単にcommitの分割を行うことができます。 使ってみる 実演の前準備 実際にtigを使って、commitの分割を行ってみましょう。 現在、sampleReposという リポジトリ が以下のような構成になっているとします。 SampleRepos/ │ └ NewFile.java NewFile. java の内容は以下の通りです。 public class NewFile { public static void main(String args[]){ System.out.println( "Hello World!" ); } } この状態で一度 commit したとします。 $ git add NewFile.java $ git commit -m "first commit" 機能を追加して、まとめてcommitする さて、この状態からNewFile. java に methodA と methodB というメソッドを追加することになりました。 public class NewFile { public static void main(String args[]){ System.out.println( "Hello World!" ); methodA(); methodB(); } public static void methodA(){ System.out.println( "methodA!" ); } public static void methodB(){ System.out.println( "methodB!" ); } } とりあえず今回の変更をまとめてcommitします。 $ git add NewFile.java $ git commit -m "add methodA and methodB to NewFile" git rebase -i で、commitの分割を始める では、早速commitを分割してみましょう。 今回は、先程の add methodA and methodB to NewFile というcommitを add methodA to NewFile add methodB to NewFIle という二つのcommitにします。 まず、以下のgitコマンドを実行します。 $ git rebase -i HEAD~1 // HEAD~の後の数字は適宜変更する. すると、以下のような文章が テキストエディタ で表示されるはずです *2 。 pick 1599a7b add methodA and methodB to NewFile # Rebase 9276511..1599a7b onto 9276511 (1 command) // 以下省略. 次に、 add methodA and methodB to NewFile のcommitを分割したいので、その横にある pick を edit へ変更してエディタを保存して閉じます。 その後、以下のコマンドを実行します。 $ git reset HEAD~1 こうして問題のcommitによる変更がunstagedな状態になりました。 （ = 変更がaddされる前の状態） tigを使ってcommitを分割する - その1 さて、この状態で以下のコマンドを実行します。 $ tig すると、次のような画面が表示されるはずです。 yyyy-mm-dd Unknown o Unstaged changes yyyy-mm-dd Committer I [HEAD] first commit これがtigの Main View と呼ばれる画面です。 この状態で、 Shift + S キーを押すと、次のような画面へ遷移します。 Interactive rebase master Changes to be committed: (no files) Changes not staged for commit: M NewFile.java Untracked files: (no files) これがtigの Status View と呼ばれる画面です *3 。 この状態で、 Changes not staged for commit: 以下の M NewFile.java にカーソルを合わせて Enter キーを押すと、次のような画面が画面下（もしくは画面右）に分割されて表示されます。 NewFile.java | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/NewFile.java b/NewFile.java index 9fde6b2..01487f8 100644 --- a/NewFile.java +++ b/NewFile.java @@ -1,5 +1,15 @@ public class NewFile { public static void main(String args[]){ System.out.println("Hello World!"); + methodA(); + methodB(); + } + + public static void methodA(){ + System.out.println("methodA!"); + } + + public static void methodB(){ + System.out.println("methodB!"); } } これが、 Diff View と呼ばれる画面です。 長くなりましたが、この画面上でstaged / unstagedする部分を指定できます。 tigを使ってcommitを分割する - その2 それでは、 main メソッド内の methodA(); と、 methodA メソッドの定義である public static void methodA(){ System.out.println( "methodA!" ); } という変更が含まれたcommitを作成しましょう。 今回は1行ずつstagedにしていきます。 Diff Viewで、commitに含める変更箇所にカーソルを合わせて 1 キーを押すことで1行づつ staged にすることができます。 ただし、 変更内容が表示された画面でのカーソル移動には j , k キーを使うことに注意します。 完了したら、Status Viewが Interactive rebase master Changes to be committed: M NewFile.java Changes not staged for commit: M NewFile.java Untracked files: (no files) となっているはずです。 つまり、同じファイルに対する変更をcommitに含むものと含まないものに分けることができた ということです。 念のため、Changes to be committedの下にあるNewFile. java のDiff Viewが以下のようになっていることを確認してください。 NewFile.java | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/NewFile.java b/NewFile.java index 9fde6b2..becff04 100644 --- a/NewFile.java +++ b/NewFile.java @@ -1,5 +1,10 @@ public class NewFile { public static void main(String args[]){ System.out.println("Hello World!"); + methodA(); + } + + public static void methodA(){ + System.out.println("methodA!"); } } q キーを押してDiff Viewを閉じてからStatus View上で Shift + C キーを押すと、 git commit コマンド入力時と同じ画面が現れます。 そこで、 commit messageを add methodA to NewFile.java. としてcommitを行います。 こうして、 methodA の追加に関する変更のみを含んだcommitが完成しました。 tigを使ってcommitを分割する - その3 その後、画面には Enter キーを押すようにメッセージが出ているはずなので、それに従います。 すると、Main Viewに画面が戻るはずです。 ここで先程の add methodA to NewFile. というcommitが表示されていない場合は、 Shift + R キーでMain Viewを更新します。 では、同じように methodB の追加に関する変更のみを含んだcommitを作成しましょう。Status Viewから、unstagedな NewFile.java に関するDiff Viewを開きます。 NewFile.java | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/NewFile.java b/NewFile.java index becff04..01487f8 100644 --- a/NewFile.java +++ b/NewFile.java @@ -2,9 +2,14 @@ public class NewFile { public static void main(String args[]){ System.out.println("Hello World!"); methodA(); + methodB(); } public static void methodA(){ System.out.println("methodA!"); } + + public static void methodB(){ + System.out.println("methodB!"); + } } また1行ずつstagedにしても良いのですが、今度は全ての変更をcommitに含みます。 なので、 U キー を押してファイルの変更全てを一括でstagedにします。 Status Viewを確認すると、以下のようになるはずです。 Changes to be committed: M NewFile.java Changes not staged for commit: (no files) Untracked files: (no files) そして、Diff Viewを閉じた状態で Shift + C キーを押して git commit を行います。 commit messageは add methodB to NewFile.java. とします。 commitが完了してMain Viewへ戻った後、 q キー を押してtigを終了します。 その後、以下のコマンドを実行して、 add methodA and methodB to NewFile というcommitへの編集を終了します。 $ git rebase --continue その後、再び tig コマンドを実行すると、確かにcommitが分割されたことが分かります。 yyyy-mm-dd hh:ss Committer o [master] add methodB to NewFile.java yyyy-mm-dd hh:ss Committer o add MethodA to NewFile. yyyy-mm-dd hh:ss Committer I first commit まとめ いかがでしたでしょうか。 ちょっと伝わりづらい部分もあったと思いますが、実際に tig を使ってみるとその便利さが分かると思います。 commitを見やすく分割するのは、レビュアーの負担を減らすだけでなく、将来の自分が変更内容を理解するのに役立ちます。 なので、この記事をご覧いただいた方が、tig を使うことで 少しでも楽に commit をきれいにできれば 幸いです。 最後に、以下の言葉を引用してこの記事のまとめとします。 コードは他の人が最短時間で理解できるように書かなければならない --- リーダブルコード - より良いコードを書くためのシンプルで実践的なテクニック P.3 より （本来はコードの可読性に関する言葉ですが、commitをきれいにするということは上記の考え方と同じものが根底にあると感じました） 参考資料 VS Code の統合ターミナルで Tig が標準装備された Git for Windows を使う gitクライアント「tig」を使いこなすための最低限覚えるべき6つのコマンド 発表に利用したスライド（一部編集済） 0330_beerbash_Fm_Harmony from 株式会社ラクス *1 : ソースコード をビルドする方法もあります。 詳しくは コチラ *2 : 当然、commit id等は人によって異なります *3 : この状態でも、ファイルごとにstaged / unstagedを切り替えることは可能です。

3月初旬に開催されたJaSST'18の参加レポートです。 [読了時間 8分] JaSST Tokyo とは 国内最大級の ソフトウェアテスト シンポジウムです。 JaSST'18 Tokyo ソフトウェアテストシンポジウム 2018 東京 日時 : 2018/03/07水～08木 場所 : 東京都 千代田区 日本大学 理工学部 駿河 台校舎１号館 参加者 : 1600人 参加費 : 2日券（早割） 8,400円 チュートリアル 受講券 10,800円を追加購入すれば、ワークショップ形式の チュートリアル 全てに参加可能 JaSST Tokyo の昨年と今年のベストスピーカ―賞の傾向（ 2017年 、 2018年 ）から、プロセス改善に注目が集まっている感もありますが、今回の JaSST'18 Tokyoの目玉はやはりなんといっても、 Google ジョン・ミッコ氏の Flaky Test だと思います。 以下では、ミッコ氏による２つのセッション 基調講演_A1「Advances in Continuous Integration Testing at Google」 基調講演者チュートリアル G5「How to identify test flakiness in your test result data テスト結果からテストの不安定性(test flakiness) を読み解く」 を取り上げて、今回参加できなかった方でも、 Google 社の先進的な取り組みについて概要を把握できるよう、ポイントを絞ってお伝えしたいと思います。（ブログに掲載することについては、ミッコ氏の許可を得ております。ありがとうございます！） 基調講演 セッション A1「Advances in Continuous Integration Testing at Google 」、基調講演者 チュートリアル G5「How to identify test flakiness in your test result data テスト結果からテストの不安定性(test flakiness) を読み解く」 講演資料 が公開されていますが、 語彙の事前知識や質疑できる場などがないとなかなか理解しにくい箇所もあると思います。 まず、趣旨（引用）とキーワードを簡単に整理した後に、セッションの要点をお伝えします。 趣旨 より効果的なテストのスケジューリングとは コストの削減方法 不安定な自動テストへの対処（Flaky Test） キーワード SETI (Software Engineer, Tools and Infrastructure) テストインフラを開発する役割 8～10人のチームに1～2名の SETI が アサイ ンされる RTS (Regression Test Selection) 実行する 回帰テスト ケース数を削減するアプローチ Transition テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移すること Edge テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移したチェンジリストの断片 Greenish テスト成功（グリーン）のような状態 確信ではなく確率 Flaky Test 不安定なテストのこと テスト結果が非 決定論 的 同じコードリビジョン、同じ入力と設定、においてテストが成功したり失敗したりする Google の自動テスト（概観） 420万の独立したテスト その16%は何がしかのFlakyさを持つ 1日あたり1億5000万のテスト実行数 平均して各テストが毎日に35回実行される 1万3000以上のチーム テスト実施の99%は成功する テスト結果がPASS→FAILに遷移したテストのうち、84%はFlaky テスト失敗の16%だけが欠陥を意味していた テストの 1.23% だけがソフトウェアの欠陥を見つけている 変更頻度が多いファイルは欠陥が埋め込まれやすい 開発者が3人以上修正したソースは欠陥が埋め込まれやすい 1人より2人がよい 3人より2人がよい 言語によって欠陥の埋め込まれ度合いが異なる C++ より Java がよい Java よりGoがよい なんというか規模が桁違いですね！ RTS はなぜ必要か テスト実行数を削減するため テスト実行の99.8%は、テスト結果の遷移を引き起こさない テスト結果の遷移を引き起こすような0.2%のテスト実行だけで十分なことになる もし完璧な アルゴリズム があれば、すべてのテストを流し続ける必要はない Greenishという概念がなぜ必要か テストの量、実行回数ともに莫大で、全てを実行しきれないため RTS だけでは問題が多い 依存関係グラフを元にした 回帰テスト 対象の選定（ RTS ）を行っても、コアモジュールへの些細な修正がほぼ全体に影響するため、一定期間の マイルストーン でのスケジューリングにおいて全テストを実行することになりがち マイルストーン 間は、プロジェクトの状態は決定的ではない（inconclusive） 全テストを実行することによる「グリーンの確信」に代わり、「グリーンの確率」を提供している 図1. Greenish 図1で、大きい緑●が「グリーンの確信」 図1で、モ スグリ ーン四角が「グリーンの確率」 チームにとってはリスクを持ってリリースすることになる 遷移を見つけるまでの時間を節約することを重視 しているようです。１日経てば「過去」であり内容を忘れている、と。 Flakyという概念がなぜ重要か テスト結果が成功から失敗に状態遷移したときでも、その84%が 誤報 であるため システムの問題なのに、開発者にテストが不合格だったと通知がくることで調査する時間が無駄になる マシンリソースの 2～16%をFlaky Testのために消費している 全てグリーンでないとリリースしないため、リリースの妨げになる 無視すべきでないときもある 図2. Flaky 図2で、Flakesはテスト結果が非 決定論 的に成功したり失敗したりするFlaky Test Flakyなテストがあると、 テスト失敗が常に欠陥を意味するとは限らなくなってしまう のです。狼少年のような存在ですね。 Flaky Testへの対処 Flaky Testを検出することで、開発者にはテスト結果に添えて「Flakyである」という旨も一緒に伝えることで、調査コストを抑える Flakyさは不可避（Inevitable）との見解 Flakyさを除去するのと同程度には新たなFlakyさが埋め込まれる Flaky なテストを単に無視したり削除するという考え方について、休憩時間にミッコ氏に直接尋ねることができました。不安定なテストはまだバグを捕まえるために価値があるので無視したり削除したりしてはならない（意訳）とのことでした。 Flaky Testの検出方法 テスト結果（PASS/FAILのバイナリ値のみ！）を残すだけで、Flaky Testへの洞察が得られるそうです。 特殊な操作は必要なく、単純なクエリで推定できるところがポイントです。 Google では テスト結果を2年間記録を残し続けている PASS/FAILのバイナリ値のみ Google では *unit.xml ファイルは残していない（が残しても構わない） テスト結果の遷移であるTransitionやEdgeに着目して、経験則を育てている 図3. Edge 履歴を共有（同じタイミングで成功・失敗すること）する他のテストの数が多い場合はFlakyではない ライブラリ起因などの明確な理由がある可能性が高い テスト結果の遷移が多いテストは、Flakyと判断できる 例えば、1日に30回もテスト結果が遷移するテストがあった場合に、開発者がそれほど頻繁に直したり壊したりをしたとは到底考えられない チュートリアル で Flaky Test の検出を実際に Google BigQuery を使って行いましたが、とても簡単でした。 感想 自動テストへの長年の取り組みの成果として、もし自動テストを全て流せるなら「確信（100% Confident）」があるという土壌があった上で、 テスト実行の運用をいかに効果的に行うか？ という次元のお話でした。 確信（100% Confident）に代わる何かが必要な状況で、 ビッグデータ 解析を活用するところがグーグルらしいですね。 クロージングパネルでも話されていた「 アメリ カでは大企業、中堅企業において自動テストは既に当たり前であり、より効果的な運用についてその興味が移っている」といった言説が印象的でした。