Chatwork Creator's Note

ご案内が遅くなりましたが、ChatWork Creator's Noteは新しいブログへ移転しました。

ChatWork Creator's Note（新）

旧ブログは現在のまま残しますが、更新はストップします。

こんにちは。アプリケーション開発部の重村(@shige0501)です。

先日 Android 版アプリ 4.10.1 をリリースしました。既にアップデートを行ってご利用いただいている方も大勢いらっしゃるかと思いますが、今回は 4.10.1 で大きく変わった画面の UI について紹介したいと思います。

変わったところ

アプリを起動してみていただくと気づく人もいるかと思いますが、メニューの配置を変更しました。

Google が推奨する Material Design では、永らく Navigation Drawer という画面左上の「≡」タップから表示される画面にメニューを配置することが望ましいとされてきました。しかし、昨年の Material Design Guidelines の更新により、 Bottom Navigation と呼ばれる画面下にアイコンを並べるメニュー構成も選択できるようになりました。

弊社の Android 版アプリは Google の Material Design に沿う形で Navigation Drawer を採用していましたが、チャットやタスク一覧の切り替えなど、主要な機能へのアクセスの導線が遠くなる問題を認識していました。 Bottom Navigation パターンがガイドラインに追加されたことでこの問題が解決されたのではないかと思います。

変更の狙い

もちろん、単純に Material Design に Bottom Navigation が追加されたから今回の UI 変更をおこなったわけではありません。 Bottom Navigation を採用することで、ユーザーが Android アプリをご利用いただく際に大きなメリットがあると確信しております。特に大きなメリットは、以下の通りです。

「チャット」、「タスク」、「コンタクト」の一覧性を向上

Navigation Drawer 採用時も未読チャット数・未完了タスク数・未承認コンタクトの件数を表示していたのですが、普段は隠れているため、これらの情報がうまく活用できていなかったのではないかと考えています。

今回の UI 変更でチャット一覧・タスク一覧・コンタクト一覧の切り替えがワンタップで可能となりました。アイコン横に件数も表示されるようにしたことで、タスクの消化状況がひと目で確認できるなど、視認性も向上しています。

また、ちょっとした工夫ですが、チャット一覧を開いた状態で「チャット」アイコンをタップすると、一覧の先頭に移動するように改善しています。

iOS 版アプリとの操作性の統一感向上

今回の UI 変更で iOS 版アプリとの操作性の統一感が向上しました。

iOS / Android で同じ画面構成となったことで、ユーザーが iOS デバイスと Android デバイスを往き来するようなことがあったとしても、違和感なく操作していただくことが可能ではないかと考えています。

残りの項目はアカウント画面で統合

Bottom Navigation はガイドライン上、配置できる最大の項目数が 5 つまでと決まっています。 Navigation Drawer 上にはそれ以上の項目が存在していましたので、別の方法でアクセスできる方法を考える必要がありました。

それらの項目の大半については、新規に追加したアカウント画面に移していますので、これまで通りプロフィール編集や設定が行えます。

まとめ

今回の UI 変更で、 Android 版アプリとしても使いやすくなっただけでなく、 iOS 版アプリと操作性の体験を近づけることができました。 今後も利便性の向上につながる改善をしてまいりますので、ご期待下さい！

最近、私がアクセシビリティ系のセミナーなどに参加していることを見た友人らから、聞かれることがあります。

「アクセシビリティって、デザイナーやコーダーなら何かできるけどその他の人って、できるところあるんですか？」と。

これを聞いてなるほどな、と思いました。セミナーやブログなどでアクセシビリティについて発信している人たちの訴える内容は、確かに、「実装」に寄り気味ですね。

今回は、Web Accessibility Advent Calendar 2016の7日目記事として、実装担当ではない人たちも関係しているよ、という部分について触れていきます。

ガイドラインの種類

Webアクセシビリティについて「あまりよくわからない」という方の為に少し補足すると、どうしたらアクセシブルなWebコンテンツが作れるか、ということに対してガイドラインが存在しています。何をしたら使いやすいか、ということに明確な指標を示してくれています。

ガイドラインの種類は3つあり、

W3Cの作ったガイドラインWCAG 2.0（日本語版）

WCAG 2.0が国際標準規格になった、ISO/IEC 40500:2012

日本の工業標準として用意されたJIS X 8341-3:2016

「日本工業標準調査会（JISC）」サイトからの閲覧（※2016年12月7日現在メンテナンス中）／「JSA Web Store（日本規格協会）」サイトからの購入が可能です。それぞれ【X8341-3】で検索ください。

すべて一致規格となっているので、現状、何を読んでも全く一緒です。しいていえば、JISが日本語である分、日本人には読みやすいかなと個人的には思いますが、「日本語が難しい」と悪名高いです。また、WCAG2.0についてはWeb上に公開されているので、いつでも閲覧／確認可能です。

詳しくは、JIS X 8341-3:2016 解説をご覧ください。

コードや見た目以外の対応

Webアクセシビリティのガイドラインには、実はデザイナー／エンジニア以外が取り組めるアクセシビリティ施策について書かれています。

例えば、原則3の「理解可能」の中には、「3.1 テキストのコンテンツを読みやすく理解可能にすること。」というのが存在しています。

詳細は読んでいただければと思いますが、その中には、一般的には使わない難しい言葉や略語は意味を提供することや、中学卒業レベルで読解不可能な文には補足コンテンツを作らなくてはいけない、ということが書かれています。とくに「3.1.3 一般的ではない用語」については達成基準を「レベルAAA」での対応事項しつつ、WCAG2.0の解説書では「レベル A、又は、レベル AA での適合をしようとしている場合であっても、この達成基準にも適合することを推奨する」と言及されています。

ガイドラインになっていますが、普通に考えてもわかりますよね。小難しい文言が並んでいても、読む方は全く意味を理解できないでしょう。

こういった対応は、実装担当ではなく、例えばディレクターや広報担当など内容を決める人が関われる部分です。

アクセシビリティとPDCA

Webのコンテンツを制作／公開する際、大概その内容の大小にかかわらず、大きく分けて

企画立案／内容の決定

コンテンツの準備

デザイン／マークアップ

内容確認／レビュー

公開

くらいの段階で制作がおこなわれていきますが、アクセシビリティ対応をする時にも普通の制作と同じようにPDCAを回していく必要があります。

この「制作フローのどこかにアクセシビリティ対応を差し込む」のではなく、全ての工程に対して少しずつ対応していけば、最後に焦って「アクセシビリティ『対応』」をおこなって行くより、ずっと工数が少なくて済みます。また、誰かひとりが頑張る、ではなく各担当者が少しずつ対応すればいいので、作業量の分担が可能になります。

「アクセシビリティ対応」とひとことで言ってしまうと、なんとなく「実装側の人にしか関係ない」と思いがちです。ただガイドラインをじっくり読んでみると、実装以外の部分でもできるアクセシビリティ対応のヒントが掲載されています。今一度、実装担当以外の人たちが取り組めるWebアクセシビリティについて考えてみるといいかもしれません。

こんにちは！アプリケーション開発部の安宅 (@at_aka) です。

先日、モバイル版アプリ v4.2.0 をリリースしました (iOS 版は 2016-09-20 火、Android 版は 2016-09-15 木、リリース)。本記事では、v4.2.0 からアクセスできるようになった「ヘルプ」を紹介します。

なにが変わったの?

チャットワークのモバイル版アプリから、「ヘルプ」をタップするとそれぞれの OS の利用ガイドにアクセスできるようになりました。アプリの使い方が分からない時、アプリの中から使い方を確認することができます。

アクセスしてみる

iOS 版アプリから「ヘルプ」へアクセスしてみます。

まず、「アカウント」を選択します (1)。プロフィールが表示されるので、「設定」をタップします (2)。設定ページをスクロールして (3)、「ヘルプ」をタップします (4)。すると、「iOS版アプリ ご利用ガイド」が表示されます (5)。

さいごに

今回用意した「ヘルプ」は、チャットワークのサポートページにあるモバイルアプリ ご利用ガイド (iOS版・Android版) と同じものです。今までモバイル版アプリから「ヘルプ」を読むためには、ブラウザーを別に起動する必要がありました。4.2.0 からはブラウザーを開かずに、モバイル版アプリの中から「ヘルプ」が読めます。

なお、「ヘルプ」の内容は PC からも見ることができます。もし興味をお持ちになりましたら、リンクを辿ってみてください。

サポート | チャットワーク（ChatWork）

こんにちは！アプリケーション開発部の安宅 (@at_aka) です。

先日 (2016-08-31 水)、iOS 向けチャットワーク・アプリ v4.1.3 をリリースしました。本記事では、v4.1.3 で搭載されたプロフィール写真及びカバー写真のアップロード機能を紹介します。

なにが変わったの？

「チャット一覧」やチャットの「タイムライン」で表示される「自分のアイコン」を iOS 版アプリからも変えられるようになりました。

変更してみる

プロフィール写真の変更

「チャット一覧」やチャットの「タイムライン」で表示される「自分のアイコン」には、「プロフィール写真」が使われています。「プロフィール写真」は「プロフィール変更」画面から変えることができます。まず、「アカウント」タブをタップして、プロフィールを表示します。自分の名前の上に、人型のアイコンが表示れています。これが現在の「プロフィール写真」です。

画面右上にある「鉛筆」アイコンをタップして、プロフィールを変更します。背景が真っ白だと、「鉛筆」アイコンが見えにくいかもしれません。そのような場合は、少し画面を下にスクロールさせてください。「鉛筆」アイコンが見えるようになります。

「プロフィール写真を変更」というリンクをタップします。

現在の「プロフィール写真」が大きく表示されました。この画面では、「プロフィール写真」の変更と、「プロフィール写真」の「公開範囲」を変更することができます。公開範囲は「公開」と「コンタクトのみに公開」の二つを選ぶことができます。

「プロフィール写真」を変更したいので、「変更する」というリンクをタップします。「写真を撮る」と「フォトライブラリから選択」の二つの選択肢が現れました。今回は「フォトライブラリから選択」を選んでみました (良い写真を撮る自信がなかったのです)。

写真ライブラリが開きます。アルバムからお気に入りの写真を選びます。隅田川の花火大会をバックに撮影したマグカップの写真がありました。Border Collie のマグカップです。これが良さそうです。写真を選択します。すると、「トリミング」画面になります。

「プロフィール写真」は円形に切り抜かれています。「トリミング」画面では、どのように切り抜かれるか分かるようになっています。円の位置をズラしり、拡大・縮小したい場合は、画像をドラッグしたりピンチ・イン、ピンチ・アウトします。OK なら右上の「完了」ボタンを押します。

「プロフィール写真を変更」画面に戻ります。再び「完了」ボタンを押すと、「プロフィール変更」画面へと遷移します。

この状態では、まだ「プロフィール写真」を変更していません。右上の「保存」ボタンを押します。すると、「プロフィール写真」がアップロードされて変更が終わります。

「チャット一覧」を見てみましょう。マイチャットのアイコンが変更されていました。成功です。

カバー写真の変更

プロフィール画面の「カバー写真」も変更できるようになりました。「プロフィール変更」画面から「カバー写真を変更」をタップします。

あとのやり方は「プロフィール写真」の変更と同じです。「カバー写真」は長方形で切り抜きます。ここでは彩り鮮やかな落雁を「カバー写真」に設定してみました。

今までの一連の動きを動画にしました。参考にどうぞ。

さいごに

チャットワーク・アプリで「プロフィール写真」を変更したいという要望は、随分前から頂いていました。Android アプリは一足早く version 4.1.0 (2016 年 6 月リリース) でサポートしています。iOS アプリでも、ようやくこの機能を提供できるようになりました。

この記事はGithubが落ちている時間で書かれました。@kyo_agoです。

今日はkarma middlewareでlocal proxyを立ててテストからサーバと通信する方法を紹介したいと思います。

karma middlewareとは

karma middlewareとはexpressのmiddlewareと同じようなもので、karmaがサーバとして動作している時に受け取った通信に対して何かしらの処理を行えるようにするものです。

実際karma自身のいくつかの機能もmiddlewareとして提供されており、設定のproxiesやfilesも実態はmiddlewareになっています。

karma middlewareの書き方

公式ドキュメントまんまですが、karma.conf.jsに以下のような記述を行うことで定義できます。 （実際の処理はpluginとして定義する）

middleware: ['customMiddleware'], plugins: [ {'middleware:customMiddleware': ['factory', function (config) { // configはこの設定ファイルが生成しているconfig objectに初期値等が追加されたもの return function (request, response/*, next */) { // 自分の処理対象外の通信の場合はnext()を呼ぶ response.writeHead(200); return response.end("content!"); }; }]} ],

上記のmiddlewareを定義するとテストコードからXHR等でkarma serverへ通信した場合、常にcontent!という内容が返ります。

proxy middlewareとは

これはkarma自体が標準で提供している機能で、設定ファイルにproxiesを書くことでkarma serverへの通信を別のサーバへ転送する機能です。

この機能を使うことにより、localhost上で実行されているkarma環境から実サーバへXHR等を転送して通信することができます。

このままならふつうに設定ファイルへ定義を記述しテストコードから実サーバへ通信すればいいのですが、通信対象のAPIがkarma環境からproxyされることを想定していない場合面倒なことになります。 （HostやOriginが違っているとか、headerをいじらないと困る場合等）

proxy middlewareの書き方

弊社ではcustomContextFileを使ってkarma上にアプリケーションコードを読み込む構成でテストしていますが、せっかくなのでAPIに対しての通信をすべてproxyできないか考えました。

実際いくつかのヘッダを書き換えることでAPIに対して通信できることがわかったのですが、karma標準のproxiesではSSLのエラー無視と通信時のOriginを書き換えられる程度で細かい制御ができません。

そこで、標準のProxy middlewareを無視して独自のProxy middlewareを差し込むことで通信の差し替えを行うことにしました。

具体的にはkarma/proxy.js at master · karma-runner/karmaを手元に落とし、karma.conf.jsに以下の記述を行います。

libProxies: { '/example/': 'https://www.example.com/' }, proxyValidateSSL: false, middleware: ['libProxy'], plugins: [ {'middleware:libProxy': ['factory', function (config) { var proxy = require('./proxy'); return proxy.create(config, config.libProxies); }]} ],

さらにproxy.js内のhttpProxy.createProxyServerの後あたりを以下のように修正します。

proxy.on('proxyReq', function(proxyReq, req, res, options) { proxyReq.setHeader('Host', 'www.example.com') proxyReq.setHeader('Origin', 'https://www.example.com') proxyReq.setHeader('Referer', 'https://www.example.com/') }) proxy.on('proxyRes', function (proxyRes) { if (proxyRes.headers['set-cookie']) { proxyRes.headers['set-cookie'] = proxyRes.headers['set-cookie'].map(function (cookie) { // karma内はhttpなのでsecureを消す。 return cookie.replace(/\s*secure;?/i, '') }) } if (proxyRes.headers['location']) { // リダイレクト先を変更（http的には不正だけど、まあ動くので） proxyRes.headers['location'] = proxyRes.headers['location'].replace(/^https:\/\/www.example.com/i, '/example/') } })

このproxy objectはnodejitsu/node-http-proxy: A full-featured http proxy for node.jsなので、詳細はドキュメントを参照ください。

この方法を使うことで/example/hogeへアクセスするとhttps://www.example.com/hogeへかなり透過的にアクセスできるようになるため、APIと直接通信してテストを実行することができました。

難消化性デキストリンやめました。@kyo_agoです。

今日はkarma 1.0.0で導入されたcustomContextFileの使い方を紹介したいと思います。 （BusterJSをご存じの方はtestbedという方が通りがいいかもしれません）

customContextFileとは

customContextFileとはkarma 1.0.0で新しくサポートされた、「指定されたhtml内からテストコードを起動する仕組み」です。

これまでkarmaでDOMに依存したテストを書くにはコード内でcreateElementやinnerHTMLを行ってDOMを構築してから実行することが一般的でした。

customContextFileを使うことによってテストコード内で使用するDOMやテストの事前処理を簡単に書くことができます。

customContextFileの使い方

customContextFileの使い方はkarma.conf.jsに以下のような記述を行います。

customContextFile: 'test/lib/context.html',

そして以下のような内容をbody内に書いたhtmlファイルを用意します。 （本家のサンプルはこちらです）

<script src="context.js"></script><script> %CLIENT_CONFIG% window.__karma__.setupContext(window); %MAPPINGS% </script> %SCRIPTS% <script type="text/javascript"> window.__karma__.loaded(); </script>

処理の詳細

上記htmlファイルは以下のように解釈されます。

context.js

karmaが提供する各種機能にアクセスするためのコードが入ったJavaScriptです。 （window.__karma__等が提供される）

%CLIENT_CONFIG%

karma.conf.js内のclientpropertyに設定されているものが設定されます。 （clearContextやmocha、args等iframe内で必要な内容が渡される）

window.__karma__.setupContext(window);

上位のiframeと通信するための設定を行います

%MAPPINGS%

karma.conf.jsのfileproperty内の内容が展開されます。 （なにに使うか今ひとつわかってないです。。。）

%SCRIPTS%

karma.conf.jsのfileproperty内のJavaScriptがscript要素として展開されます。

window.__karma__.loaded();

karmaの起動処理です。

このコードの呼び出しを遅延するとkarmaの呼び出しを遅延させることができます。

実際の使い方

弊社ではこのcustomContextFileで指定したhtmlファイルに本番環境と同じようなhtmlを記述し、テストごとに毎回develop環境をまるごと読み込ませてテストをこなっています。 （アプリケーションの初期化を行ってからwindow.__karma__.loaded();を呼び出す）

karmaはそのままだとテスト毎に環境をクリアしますが、clearContextを設定してテスト毎の環境のクリアを停止することで「実コードと同じ場所にmochaを入れてテストする」ことができます。 （もちろん環境のクリアが行われないためmock, stub等は毎回自分でクリアする必要があります）

骨折しました。@kyo_agoです。

今日はTravisCI上で実ブラウザ環境のテストを行う方法を紹介したいと思います。

弊社ではこれまで実ブラウザ環境のテストではTravisCIからProtractorを使ってSauceLabsへ接続してテストを行っていました。

しかし、これには以下のような問題があったため、ProtractorとSauceLabsを使用しない構成へ移行しました。

テストが高頻度で失敗する

テストに影響しない部分の修正ですらテストが失敗し、コードの修正よりテストを通すほうが難しい状況になっていました。 （これは社内では「e2eガチャ」と呼ばれ、レビュー依頼のコメントには「e2eガチャ 1/5」と成功率が書かれていました。ちなみに「1/5」はわりといい確率です。悪い時は「1/12」くらいになります）

遅い

SauceLabsへの接続時間、WebDriver経由のテスト実行などはかなり重い処理になり、これだけで数分かかる状態でした。

また、それぞれのテスト実行が1テストごとに数秒かかるため、今後このままテストを追加していくと単純にテスト実行時間が伸びていく懸念がありました。。 （1テストに数秒かかるのはexecuteAsyncScriptやexecuteScriptを使用しているのが原因のようだったのですが、書き換えが困難だったため対応を検討していました）

デバッグが難しい

Protractorが内部で使用しているWebDriverはChromeのDebuggerと共存することができないため、Protractorを実行中にChromeのDevToolsを開くことができません。

Protractorはコード上に記述したconsole.logの出力をターミナルへ転送してくれますが、インタラクティブな操作ができないため通常のDevToolsと比較するとデバッグが非常に困難です。

依存サービスが増える

単純に依存サービスが増えるとサービスダウンのリスクも増えます。 実際SauceLabsもサービスダウンすることがあり、その間はテストの実行ができなくなりました。

また、サービスはダウンしていなくてもTravisCIからSauceLabsへの接続に失敗することもあり、その場合もテストの実行ができません。

上記のような問題から弊社ではTravisCI上でFirefoxを起動してkarmaを使う構成へ移行しました。

これにより、外部サービスへの依存とWebDriverが不要になり、テストの実行が安定かつ高速になりました。

また、テスト実行中もDevToolsが起動できるためデバッグも非常に容易です。

ただ、これには以下のようなデメリットもあります。

録画、実行ログがない

SauceLabsではテスト実行中のブラウザ動作、WebDriverの通信ログを保存していますが、TravisCI状のみで完結する場合そういったサポートは受けられません。

クロスブラウザの検証が困難

後述しますが、TravisCI上のChromeはバージョンが古く、テストの実行環境として使用するには向きません。

また、当然Safari、IE、Edge、スマートフォンブラウザ環境も存在しないため、クロスブラウザテストを行う必要がある場合SauceLabsが必要になります。

実行方法が特殊

Protractorではテスト環境のURLを指定すれば、そのまま環境を読み込んでテストを実行できます。

しかし、karmaはWebDriverを使用していないため読み込み先はlocalhostになります。

サーバとの通信方法も検討する必要があるため、場合によっては本体のコードへ手を加える必要があります。

ログの出力が微妙

細かい部分ではありますが、TravisCIのWebコンソールとkarmaの相性が悪いようでExecute SUCCESSの表示が若干乱れます。 （テストが失敗した場合は正しく表示されるため現状気にしていません）

実際の設定方法に関しては基本的にはkarma、TravisCIのドキュメントに書かれていますが、一点詰まる部分があったためその解決方法に関して紹介したいと思います。

TravisCI上のChrome(Ubuntu Chronium)はバージョンが古い

現在提供されているTravisCIのChrome(Chronium)のバージョンはChromium 37.0.2062です。

また、上記Issueにも上げられていますが、標準だとFirefoxもバージョンが古いため注意が必要です。

これに関しては「sudo apt-getする」方法が紹介されていますが、sudo apt-getするためにはsudo: requiredも必要になります。

そのため、弊社では.travis.ymlに以下のような指定を行っています。

addons: firefox: "latest" # この指定で最新のFirefoxが使用できる before_script: - export FIREFOX_BIN=`which firefox` - export JPM_FIREFOX_BINARY=`which firefox` script: - xvfb-run karma start --single-run

昨今流行りの IoT。 ものとインターネットをつなげて云々…

IoT とひとくちに言ってもいろいろあります。 その中でも自動車や家電とインターネットをつなげた、製品として開発されているものであれば、見たり耳にすることがよくあると思います。

また、最近では手頃に入手できて、簡単に取り扱えるセンサー類や、WiFi を搭載したマイコンボードなどもあるので、趣味の範囲でインターネットと何かをつなげたデバイスを作ることもできます。

そこで、この記事では、私、フロントエンドチームの西口が趣味として作ったガジェットの一例を、チャットワーク社のクリエイターズブログということで、そのガジェットとチャットワークをつなげてみた、というお話をご紹介していきます。

コミュニケーション効率化による生産性アップだけがチャットワークじゃない

チャットワーク の利用目的のメインは言わずもがなビジネスコミュニケーション。 社員同士や取引先などとのやり取りに使うことでコミュニケーションコストを抑え、生産効率を上げることです。

しかし、チャットワーク の活用方法はそれだけには留まりません。 先ほど言ったように、ものとチャットワークをつなげることで、チャットワーク 活用の幅をさらに広げることができるのです。

ものとチャットワークをつなげると言っても…

でも、実際にどういうものを作れば活用範囲を広げられるのか、なかなか見当がつかないと思います。

そういう時は、日常業務のなかで、そこで働くみんながどういったことで困っているのかを観察してみることです。そうすると何かヒントを見つけられることがあります。

例えば、弊社では社内の備品管理をチャットワークのグループチャットでおこなっています。

備品がなくなれば、最後に使った人がそのチャットで担当者に購入依頼のタスクを振る、といった具合です。

ですが、購入依頼をするところは人力のため、本来の業務が忙しかったりで、どうしても忘れてしまうことがあり、それは仕方がありません。

では、この依頼タスクを振る部分をどうにか自動化できないか？？ こういったきっかけがヒントになり、ガジェット開発につながっていきます。

備品購入依頼を自動化するガジェット

これで、どういうものを作れば良いかが見えてきました。 では、次にそれをどんな仕組みで実現していくのかを考えていきます。

今回は、備品が少なくなってきたら購入依頼をチャットワークに送信する、ということが処理できるものです。

タスクをチャットワークに送信するのは チャットワーク API でできそうなので、メインで考えることは、備品の在庫が減ってきたことをどう知るかと言う部分になります。

その方法は幾つかあると思いますが、今回は一番シンプルな備品の重さによる方法にしました。 重さを採用した理由には、購入依頼処理を実行する閾値を調整するだけで、あらゆる備品に対応できそうかな、という期待もありました。

技術とガジェットの構成を検討する

デジタル体重計をハック

仕組みのアイデアが揃ったので、次は重さをどういう技術で検出するかの検討が必要になります。

まずはじめに考えたのが重さ（圧力）センサーでした。

数百円で売られているのでコスト的には魅力ですが、検出できる重さの範囲が狭く、重量のある備品には向かなそうなので、諦めました。

次の候補はキッチンスケール。 ということで、ネットでいろいろ検索してみましたが、キッチンスケールも数Kg程度まで量れるものしかなく、備品の重さ検出には使えなさそうでした。

キッチンスケールよりも計測範囲の広いものということで、次に検討したのがデジタル体重計でした。

1,000円弱と重さセンサーよりは高価になりますが、手が出ない程でもなく問題のない範囲です。ということで、今回はデジタル体重計を使うことに決めました。

ESP-WROOM-02 安価のWiFiモジュール

重さ検出にデジタル体重計を使うことが決まりましたが、検出した重さをゴニョゴニョしてチャットワークとつなげる、ガジェット全体の構成を決めなくては、実際の開発に進むことができません。

大まかな構成としては、重さをはかるデジタル体重計と、その重さを入力として処理し、チャットワーク API と通信をおこなうマイコン部分のふたつになります。

この構成では、マイコン部分でチャットワーク API との通信が必要になり、ネット接続が要件として挙がってきます。

そこで候補になるのが、WiFi 内蔵、そして、個人的に以前から使っていた Arduino プログラムが書き込める ESP-WROOM-02 という Wifi モジュールです。

ESP-WROOM-02 というのは Espressif Systems 社から出ている WiFi チップ ESP8266EX をベースにした WiFiモジュールになります。特徴としては…

Arduino IDE で開発でき、Arduino プログラムを書き込める

GPIO や AD コンバータなどの多種のインターフェースを搭載している

コンパクトなサイズ

技適取得済みなので、日本でも問題なく使える

などなど。

Arduino UNO などのように USB ケーブルでパソコンと接続してすぐにプログラムを書き込む、ということができないので若干使いづらい点はありますが、プログラムの書き込み方法はネットで簡単に見つけられるので心配なしです。

そして、600円程と気軽に初められる価格のメリットもあり、このESP-WROOM-02 を使うことにしました。

実際に運用してみる

そんなこんなでできあがった備品管理ガジェット！（一気にスッ飛んだ感がありますが…）

実際にオフィスで運用してみます。 依頼漏れが比較的多かった、お客さまにお出しするペットボトルのお茶の在庫管理をすることにしました。

一時間に一回、計測したお茶ケースの重さをチャットに送信します。 業務時間中は、お茶を取り出したり、箱を整理したりで計測値の変動が考えられますので、購入依頼をかけるのは業務開始前の朝8時台に計測した時だけにしました。

また、一度購入依頼を出した後は、リセットボタンを押すまでは再度依頼しないように、依頼重複を防止する処理もいれました。

と言う動きを期待していますが、実はまだ運用開始より日が浅く、購入依頼はまだ出されていません…。

しばらく一時間に一度のメッセージをモニタして、きちんと計測できているか様子を見ようと思っています。 在庫が少なくなってきた時に無事に発注タスクがチャットワークに投稿されれば大成功！

まとめ

体重計をハックして備品の購入依頼を処理するガジェットを作ってみました。

それまで人力で処理していた備品の購入依頼を自動化することができました。

つまり言い換えると、備品発注依頼という雑務に割かれていた時間が必要なくなり、その分本来の業務に各自のリソースを集中させることが可能になったということです。

このように、ちょっとしたアイデアからチャットワークの活用範囲を広げられる結果につなげられました！

今回は、記事が長くなりそうだったので、ガジェットの作成やプログラミングといった開発部分の話を端折りましたが、それらはまた別の機会に開発編として記事を書こうと思います。（乞うご期待！）

チャットワークで働く私たちのことをもっと知って欲しいということで、ポッドキャストを始めました。 １ヶ月に１回のペースで、社員の何人かが集まって仕事のことや、業界のことについてあれこれ話します。

今回は弊社デザイナーが集まってデザインツール Sketch について雑談しました。どうやって使っているのか、工夫していること、困っていることを共有しました。

番組で紹介した Sketch プラグインを紹介します。

soutaro/Align-text-baseline-sketch-plugin

Arkkimaagi/ArtboardZoom

timuric/Content-generator-sketch-plugin

webpatch/Handy-Tools

t32k/material-design-color-palette

rodi01/RenameIt

zmalltalker/sketch-android-assets

getflourish/Sketch-Color-Contrast-Analyser

bomberstudios/sketch-commands

ichord/sketch-divine-proportions

ddwht/sketch-dynamic-button

utom/sketch-measure

buscarini/sketch-plugins

joshpuckett/SketchPlugins

getflourish/Sketch-Set-Line-Height-Plugin

getflourish/Sketch-Sort-Layers

PEZ/SketchDistributor

ozzik/swap-styles

andrewfiorillo/sketch-palettes

こんにちは。そしてみなさん初めまして、フロントエンドエンジニアの奥野です。

Twitterなどでは@armorik83として活動しており、Qiitaにて『AngularJSモダンプラクティス』を掲載したところ、とてもご好評頂きました。また、京都市出身でng-kyotoというAngularJSユーザグループの代表も務めています。

そんな私ですが、この度弊社の@kyo_agoと知り合った縁がきっかけで9月より入社と決まり、すぐさま京都から引っ越しフロントエンドエンジニアとして配属されました。

第60回HTML5とか勉強会 －ECMAScript 2015 & 2016－にて登壇

入社して間もないころ、突然「HTML5とか勉強会」への登壇オファーが舞い込んできました。HTML5とか勉強会とは、HTML5を中心に取り扱うコミュニティhtml5jが定期的に開催する勉強会で、今回のテーマはJavaScriptの標準仕様であるECMAScript 2015、そして次期仕様提案（ES7, ES.nextとも呼ばれる）の二本です。これは9月29日に日本マイクロソフト品川本社にて開催されました。

弊社ではフロントエンドにTypeScript, BabelといったJavaScriptの新構文・新仕様を積極的に採り入れており、私も早速業務でBabelをフル活用していたものですから、すぐにこのオファーを引き受けました。今回取り扱ったのはES2015ですらなく、その先、"ES7 Decorators"です。

Decorators構文の詳細については、当日の資料や映像、または資料内で紹介している記事をご覧ください。

ChatWork初のnpmパッケージ "wrasse"

今回の登壇ではひとつ隠し玉を用意。それがこのライブラリ、"wrasse"です。

社内でも早速「わっせー」と呼ばれ親しまれているこれは「ラース」と発音し、日本語では魚の「ベラ」を指します。たまたまフロントエンドのプロダクト・コードネームに魚のものがあったので、じゃあこれも魚にしようという思いで名付けたんですが、九州では「クサビ」とも呼ばれる魚で、クサビのようにclassにコンポーネントを注入するDependency Injection風のライブラリとなっています。

使い方

なにはともあれインストール。

npm i -S wrasse

wrasseは事前にインスタンスを生成し、そこにあらかじめ注入したいコンポーネントとそれを実装中で呼び出すためのキーをペアで登録する必要があります。

import Wrasse from 'wrasse';

wrasseのimportはこの一箇所のみで、今後は生成したインスタンスを使っていきます。

こうやって登録したコンポーネントは、使用したいclassに対してDecorators構文で記述することによって、使うときにはすでに注入済み、という夢の様なことができます！

テストではbeforeEach()やit()内などでインスタンスに対してモックをセットすればOKです。

Decorators構文を用いているので、BabelやTypeScriptではオプション指定が必要です。

$ babel --optional es7.decorators

$ tsc --experimentalDecorators

DIが必要となった背景

私はJavaScriptフレームワーク"AngularJS"を2年以上使っていますが、このフレームワークの特徴として挙げられるDIは、モックテスト、テストダブルを行う上でとても有用な機構でした。この機構を用いないとコンポーネントは密結合となり、テストのたびにモックが使えず、すべてのインスタンスを用意する必要があります。

wrasseではそこを解決し、さらに記述しやすい、学習コストが低い、をモットーに設計しています。みなさんのテストの助けになれば幸いです。

なお、このwrasseの開発にあたりng-kyotoオーガナイザであり友人でもある@_likr氏と、テスト駆動開発の第一人者である@t_wada氏からたくさんの助言を頂けましたので、この場を借りてお礼申し上げます。

弊社案件で早くも活躍しているwrasseですが、OSSとして公開していますので広くお使いいただけますし、フィードバック、PRも大歓迎です。ぜひ、ES7とともにお試しください。

JavaScriptの先、さらにその先に行きませんか？

弊社ではES2015, Babel, TypeScriptだけでなく、フロントエンドにScala.jsも採用し積極的に最先端のJavaScriptに挑み続けています。より新鮮な開発環境で新しいものに挑戦してみたいエンジニアの方！ぜひ下記のリンクからどうぞ。

最近窓にすだれを取り付けました。@kyo_agoです。

2015/07/14に社内でScala.jsの勉強会を開催しました。

Scala.jsはまだ社内でも知見が少なく、割と突発的なイベントだったのですがなかなか濃い内容になったのでレポートしたいと思います。

Scala.jsとは

Scala.jsとは、Scalaで書かれたコードをJavaScriptに変換して実行できるようにするコンパイラです。

開発は2011/12/31から始まっており、2014年に入ってから話題になってきたようです。

形式

何人かが資料を作って持ち寄り、随時発表をする形式で行いました。

登壇者

「TypeScript経験2年（Scala経験0）」から「Scalaはソースまで読んでる（JavaScript経験0）」まで幅広く、多彩な発表で非常に盛り上がりました。

内容

ざっくりこんな感じの話でした。

Scala.jsの何がつらいか

sbtをどう理解すればいいのか

sbt昔話

sbtでJavaScriptのライブラリを管理する方法

Isomorphic。同型（矢印）

TypeScriptとの比較

出力後のJavaScriptコードの読み方

Scala.jsのコンパイルオプション紹介

Scala.jsをsbtなしで使う方法

JavaScriptからScala.js内で定義したfunctionを呼び出す方法

情報の探し方

Activatorとの連携方法

エディタはどうすべきか

npmとの連携方法

JavaScript側から入門したい場合どこから入ったらいい？

JavaScript側のエコシステムに載せるには？

JavaScriptとScalaの言語としての比較

Scala.jsでフロントエンド入門してみた

HelloWorldが書けたのでFreeモナドを書いてみた

Coyonedaも動かしてみた。Shapelessも動くとか

Scala.jsでリバーシを実装してみた

Scala.jsのテスト事情

DOMやJavaScriptライブラリとScala部分との連携

二槽式アーキテクチャの紹介

Scala.jsの制限

Scala.js自体のリスク

Scala側から見たScala.jsのポジション

JavaScript側から見たScala.jsのポジション

感想

基本的に非公開前提の勉強会だったのでほんとにざっくりした内容で申し訳ないです。

JavaScript経験者から「Scala界から見たScala.jsのポジションがわかった」、Scala経験者からすると「JavaScript側のエコシステムがわかった」との声がありました。

個人的にはScala使いの人が「これなら本気出して大丈夫」と言っていたのが印象的でした。

もし興味がある内容があれば勉強会に参加したメンバーの多くが2015/08/01のScala関西 Summit 2015に参加するため、捕まえていただければお答えできると思います。

2015/06/26にアラタナさんとチャットワークとでDDD×Scalaの合同勉強会を開催しました。 アラタナさんの宮崎本社とチャットワークの東京オフィスをビデオ通話でつないでの合同勉強会でした。

この勉強会はクローズドイベントだったので、参加したくてもできない方がたくさんいたと思います。なので、Web開発部のチバがレポートをします。めちゃくちゃ楽しかったので、参加したくてもできなかった方たちのためにめちゃくちゃ楽しかったことをレポートします。

アラタナさんも当日の様子を「僕らの継続的ビール摂取型ドメイン駆動設計（ChatWork ✕ アラタナ合同勉強会）」という記事に書いてくれました！

準備

宮崎と東京でインターネットを使って勉強会…なんてインターネットっぽい勉強会なんだ…！と思っていたら、アラタナさんが来社。しかも勉強会中に食べる食事を持って来てくれました！！！

DDDおじさんが突然のプレゼン

アラタナさんが宮崎と東京を繋げます。インターネットを使ったビデオ通話で。 つなげる準備をしている間にDDDおじさん(かとじゅん)が突然のプレゼンを始めました。DDDの概要みたいなことをまとめてくれていたのですごく勉強会っぽい雰囲気になりました。

乾杯

ビデオ通話の準備が整い、宮崎と東京が距離を超えて繋がりました。インターネット万歳です。

そして乾杯です。皆がアルコールの摂取を開始します。アルコールだけでは内臓に負担がかかるので糖質も一緒に摂取しました。

今回のテーマの発表

アラタナさんから今回の勉強会で扱うテーマの説明です。今回のテーマは図書館の貸出サービスです。具体的な内容は下記の様な感じです

利用者について

図書は書籍と雑誌に分類できる

利用者は一般利用者と特別利用者に分類できる

一般利用者は一度に10冊まで貸し出しできる

特別利用者は一度に15冊まで貸し出しできる

利用者は借りた本を2週間以内に返却する必要がある

図書について

図書は不定期に入荷する。入荷して1ヶ月以内の図書を新着図書と呼ぶ。ただし、既に蔵書にある場合はその限りではない

新着図書は一度に3冊までしか貸出できない

廃棄した図書は記録する

貸出予約について

利用者は他の利用者が貸し出しているときは貸出予約を行うことが出来る

貸出予約は一度に5冊までできる

貸出予約を行って、図書が貸出可能になって1週間経過しても貸出を行わなかった場合は貸出予約は取り消される

返却について

2週間以上返却を延滞した場合は、2週間貸出できない

返却延滞中の図書がある場合は貸出できない

利用者は図書を紛失した場合は、紛失届を提出しなければならない

1年以内に2回、紛失届を提出した利用者は半年間貸出できない

ワークショップ

説明が終わり、宮崎は2チーム・東京は3チームに分かれ飲酒をしながらのワークショップです。 参加者にエンジニアではない人もいます。いろんな人が混ざって議論ができるのがDDDっぽいです。 DDDおじさんも「エンジニア用語を使わないように」と言っていました。ユビキタス言語ってヤツですね。

その後、各チーム別々の場所でモデリングをしました。

模造紙を広げポストイットにモデルの名前を書きながら貼りながらモデル同士を関連付けたりとか

ここはこっちじゃない？いやいや、いやいやいや…とか、あれ？そしたらこれが必要じゃない？とか

一般会員と特別会員って何？どうしたら特別会員になれるの！？きっと何かの条件でそうなるんだからそれはコンテキストの外の話だよね、とか。時間がないので機能を削ろうとする人と、せっかくなのでちゃんとサービスを考えたい人で対立したりとか。

斬新な概念も出てきました。飲酒をしていなければなかなか出てこなかっただろうなと思います。

結果発表

血中アルコール濃度も高まってきたところで、それぞれのチームの結果発表です。

それぞれのチームが図書館業務の概念様々なユビキタス言語でモデリングをしていました。 出来上がったモデルたちを見ながらみんなでワイワイ話したりしました。

各チームの発表が終わり、最後はみんなであーだこーだ話してました。

ただ、僕の血中アルコール濃度がこの時点でそこそこ高めだったので、余り覚えてないです。

感想

ドメインエキスパートがいて、その人に質問をしつつ一緒にモデリングをしていっていたらまた違った結果になっていたのかもしれませんね。 ただ、こういう風に国語で議論できるというのはめちゃくちゃ楽しいです。DDDめちゃくちゃ楽しい。

最後に

チャットワークではこのような楽しい社内勉強会が頻繁に開かれています！ 参加したいという方は下記のリンクから参加申請してください！！

こんにちは、先日Web開発チームに加わりました西口です。

HTMLメールの制作って煩わしくないですか？ おそらくそう感じているWebデザイナーの方は多いのではないかと思っています。

HTMLメールの制作って大変

特に下記のような点が挙げられると思います。

テーブルレイアウト（コーディング面倒…）

インラインCSS（コーディング面倒…）

メールクライントごとで差のあるCSS対応（表示チェックどうすんの…）

各種メールクライアントでの表示テスト（古い環境もまだまだ現役…）

などなど…

弊社でもHTMLメールはそこまで頻繁に作成することがなかったので、これまでワークフローを見直すことがなく、ヘイトの増加を感じつつもHTMLを直接コーディングして作成していました。

ただ、やはりこういうフローでは時間がかかってしまったり表示確認が面倒だったので、どうにか効率良くならないかと調べていたら、HTMLメール作成用のGruntプラグインがありました。

試しにそれらを使ってみたところ、以前に比べて効率が良くなるなと感じた点があるので、今回はそれらのツールを紹介してみたいと思います。

CSSをインラインで書くのが面倒

まずは、CSSのインライン化をしてくれる grunt-premailer というツールです。

CSSに記述されたスタイル定義を該当のHTML要素にインラインスタイルとして追加してくれるツールです。簡単に言うと、別々にコーディングしていたHTMLとCSSをガッチャンコして、HTMLメール用のファイルを生成してくれます。

このツールを使うと、CSSコーディングは、SassやLESSを使って書くことができるので、いつもと同じ感覚で進められます。

これだけでも、作業時間は随分削減された印象です。

使い方は、

npm install grunt-premailer --save-dev

でインストールして、Gruntfile.js にタスクを追加、

optionsの設定類はプラグインのページを参照してください。

あとは、HTMLとCSS（テンプレートエンジンやCSSプリプロセッサを使っている場合は事前にビルド）を用意して、タスクを実行するとCSSがインライン化されます。

メールクライアント毎の表示確認が面倒

メールを見る環境は、ブラウザやメールクライアントアプリなどさまざまな種類、パソコンやモバイルなどさまざまなデバイスがあります。

また、メールクライアントによってCSSの対応状況もバラバラということもあり、できればより多くの環境で表示確認をおこなうのが理想ですが、それを実現するのもまたまた面倒です。

そこで、次に紹介するのはHTMLメールの表示確認を手助けしてくれる、grunt-mailgun と grunt-litmus というふたつのツールです。

メールのテスト送信をする grunt-mailgun

こちらのツールは、メール配信サービスのMailgunを使ってローカルのメールをテスト送信するツールです。

Gruntタスクでメールを送信できるので、すぐにクライアントアプリなどでの表示確認がおこなえます。

使い方は、いつものようにプラグインをインストールして、

npm install grunt-mailgun --save-dev

タスクを追加しますが、こちらのツールは、Mailgunのサービスを利用するため、事前にアカウントを作成し、apiキーを取得しておく必要があります。テスト送信程度であれば、無料プランでも充分だと思います。

また、有料プランでは分析などのメールマーケティングに使えそうな機能も提供されているようです。詳しくはサイトをご覧ください。

Gruntfile.js に自分のapiキーを書いておくのが不安という場合は、別ファイルに記述して、共有しないようにもできます。

他のメール配信サービスだと、送信するのにあれこれ設定が必要だったりするところが、このツールではコマンド一発で送信できるので、表示確認するのがすごく楽になります。

クライアント毎の表示確認が一度にできる grunt-litmus

次のツールは、HTMLメール（Webページ）の復数環境での表示確認ができるサービス litmus を使用して表示テストするためのツール、grunt-litmus です。

このツールはlitmusを使用してのテストのため、事前にlitmusのアカウントが必要になります。

今回は試した程度で、無料トライアルでの利用だったため、確認できる環境がふたつ（Outlook2003とIEのGmail）だけでしたが、有料プランでは30以上のクライアントでの表示確認が可能なようです。

まずは、プラグインのインストール

npm install grunt-litmus --save-dev

タスクを追加、

このタスクでも、同じく username や password は別ファイルで管理しておく方が良いでしょう。

タスクを実行すると、litmusのテストにローカルのhtmlメールのデータを送信してくれます。 そして、送信が完了したら、litmus上で設定した環境ごとでの表示確認ができます。

一度に復数環境での表示確認ができるので、確認作業の時間がかなり短縮されます。

HTMLメールワークフロー

最後に紹介するのは、今回ピックアップしたツールに加え、テンプレートからのHTMLビルド、Sassのコンパイルなど、HTMLメール制作の一連のワークフローをGruntタスクとしてまとめてくれている、grunt-email-workflow です。こちらは、先ほど紹介したMailgunの中の人が公開されているようです。

Gruntタスクだけじゃなく、CSSプリプロセッサにSCSS、テンプレートエンジンにHandlebarsを利用したメールの雛形も用意されているので、これだけですぐに試してみるということも可能です。

HTMLメールの制作をどうにかしたいと感じている方が、まずは今回紹介したようなツールを試してみたいという時に手軽に始められるのではと思います。

まとめ

HTMLメールの制作を手助けしてくれる3つのGruntプラグインを紹介しました。

ひとつはCSSをインライン化してくれる grunt-premailer。 次に、表示確認につかえる、grunt-mailgun と grunt-litmus です。

そして、HTMLメールのワークフロータスクをひとまとめにした Grunt Email Design Workflow もとりあげました。

HTMLメールのような単発で発生するような制作タスクでも、ワークフローを見直し効率化することで、普段と同じ感覚で作業を進められたり、また、メインタスクの作業時間の確保にもなり、その効果は少なくないように思います。

Web開発チームの尾崎です。もう夏のように熱くなってきましたね！ そんな、ある日のことWeb開発チームのマネージャーからタスクが降ってきました

( ﾟдﾟ) ・・・

(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ) ・・・

(つд⊂)ｺﾞｼｺﾞｼｺﾞｼ

（；ﾟДﾟ） …！？

自分の評価のためにもやるしかないです！

MAKIBOT

http://sanographix.github.io/makibot/

MAKIBOTはGitHub社が提供しているBOTフレームワークのhubotで作られたラブライブの西木野真姫さんのBOTです。 別チャット用に作られたものですが、hubot-chatworkというものがあるので、こちらを使ってChatWork上で会話できるようにします。

関係ないですが、ラブライブは1期の3話でMP全損して視聴を断念しましたが、海未ちゃんが可愛いのは知ってます。

MAKIBOT+hubot-chatwork

という訳でMAKIBOTを動かせる状態にします。 と、言っても簡単で

git clone https://github.com/sanographix/makibot.git

でソースを持ってきて

https://github.com/sanographix/makibot/blob/master/package.json#L26

"hubot-chatwork": "~0.1.0",

該当箇所を書き換えて

heroku apps:create makibot heroku config:set HUBOT_CHATWORK_TOKEN="DEADBEEF" heroku config:set HUBOT_CHATWORK_ROOMS="123,456" heroku config:set HUBOT_CHATWORK_API_RATE="350" heroku config:set HUBOT_TUMBLR_API_KEY="xxxxx" heroku addons:add rediscloud git push heroku master

herokuにプッシュしてChatWorkのルームに招待すれば、可愛い西木野真姫さんとキャッキャウフフすることができます。

なんて、簡単な話がある訳ありません。

そのまま入室させると西木野真姫さんの独り言がルームを占拠します。（実際は画像の数10倍の発言で埋め尽くされて酷い目にあいました）

という訳でChatWorkでhubotを動かすのには少し手間をかけてあげる必要があります。

hubotの入室前にメッセージAPIを一度叩く

http://developer.chatwork.com/ja/endpoint_rooms.html#GET-rooms-room_id-messages

メッセージAPIは未読のメッセージを100件取得する仕様のため、入室時点で100件メッセージがあるとhubotがその100件に反応してしまいます。 そこで、新しい部屋にhubotを入室させる場合は必ずメッセージAPIを叩いてください。

curl -X GET -H "X-ChatWorkToken: 自分のAPIトークン" "https://api.chatwork.com/v1/rooms/{room_id}/messages?force=0"

BOTが自分の投稿したメッセージに反応する

hubot-chatworkを使うとBOTが自分自身の発言に対しても反応して、運が悪いと無限ループに入ります。 これは、ChatWork APIが自分自身の発言を返さないようにするのか、hubot-chatworkが自分自身の発言は除外するようにするのか、hubotでscriptを書くときにループしないように組むのか、どこで対応するのが良いのかちょっと悩ましいです。

が、今回は一番手軽に対応できるhubot-chatworkを書き換えて、自分自身の発言を除外できるようにしてしまいます。

https://github.com/k-kinzal/hubot-chatwork/commit/ff68fe53caccd065f4f6ce96ccd2c4f9ff430b04

上記コミットを参考に、hubot-chatworkをforkして書き換えて

heroku config:set HUBOT_CHATWORK_EXCLUDE_ACCOUNTS="123"

とBOT自身のアカウントを指定してください。

そのうち気が向いたらPR送るかもです。

おわりに

という訳で、うちのマネージャーはたまに西木野真姫さんとキャッキャウフフしています。

はじめまして。アプリケーション開発部（Androidチーム）の重村（@shige0501）です。

先日弊社の宮下がポストした「これからのChatWorkのAndroidアプリ戦略」で少し触れられましたが、３月１日よりChatWorkに入社し、モバイルアプリケーションエンジニア（Android担当）として日々Androidアプリの開発に携わっています。

普通の転職であれば特にこれ以上取り上げるような話もないように思えますが、私の働き方がちょっと他と違うので、少しお話させていただきます。

どうやって働いているのか？

一般の企業であれば、公共交通機関や自転車・自動車などを利用して出社し、自分の席で一日の仕事をして帰るという流れになるでしょう。私も前職まではその働き方しか知りませんでした。

現在は完全なリモートワーク（在宅勤務）に挑戦しています。

弊社の主力サービスであるチャットワークはリモートワークにもしっかり対応できるツールであることから、チャットワークをフル活用しながら山口県にある自宅からリモートで勤務するということに挑戦しています。

初めてのリモート勤務ということで最初は戸惑うことも多かったですが、２ヶ月ほど経った頃からようやくリズムが掴めてきたかなと感じています。

エンジニアリングのための環境

会社からは開発に必要な以下の様な機材が提供され、ストレスフリーで仕事をしています。

MacBook Pro Retina 13inch

評価用Android端末（Nexus 6）

27inch ディスプレイ

もちろん機材があるだけでは開発はできません。エンジニア間のやりとりはGitHubでPullRequestを利用して行いつつ、平行して弊社のチャットワークでプロジェクト専用のチャットルームを作って頻繁にやりとりをしつつ、ChatWork Liveでビデオチャット会議する・・・といった働き方をしています。

もともと弊社がリモートワークを前提とした業務の仕組みができている（社長がシリコンバレー在住ということもあって）ので、周りの同僚も大きな混乱なく受け入れて貰えています。

もちろん、チャットとビデオチャットだけのやりとりではどうしてもコミュニケーション不足となってしまいますので、毎月１回ぐらいのペースで大阪か東京のオフィスに勉強会参加などのタイミングに合わせて出社し、顔を突き合わせた議論も行うようにしています。

リモートワークならではの利点とコミュニケーション

リモートワークならではの利点、それは出退勤がない点がまずは挙げられるでしょう。

以前はできなかった娘を保育園に連れて行くなど、家族とのコミュニケーションも以前より増えたように思えます。私の自宅には犬と猫がいるので、休憩がてら彼らと日々触れ合うことができるのも、リモートワークの利点のひとつとして挙げられると思います。

弊社内では部活動が盛んで、社内のチャットに猫と犬の写真を日々あげていたら、”癒し部”という部活チャットがいつの間にか生まれ、いつの間にか部長に就任していました。 リモートワークすることで、こんなところからもコミュニケーションが生まれ、社内が活性化するのは私にとっても新しい発見でした。

リモートワークの辛いところ

ここまでリモートワークのいいところばかりを挙げてみましたが、リモートワークならではの辛いところもやはりあります。

リアルでのコミュニケーション不足

運動不足

仕事とプライベートの切り分け

リアルでのコミュニケーション不足

こちらはリモートで働く以上、避けて通れない点です。 上記にも書きましたが、なるべく大阪や東京のオフィスに行った時にコミュニケーションを取る時間をしっかり取って行くことが重要になります。弊社では食券制度という、昼食を社員同士で食べたら一定金額まで会社から補助が出るという制度もあるので、そちらを有効活用しながらコミュニケーション欠乏症にならないように気をつけています。

運動不足

実は今一番気を付けないといけないのが運動不足です。 前職の時には通勤に電車も含めて１時間近くかかっていたこともあり、往復で３０分ぐらい歩いていたことが運動不足解消となっていました。 現在は通勤時間０分ですから、意識的に散歩の時間などを設けて運動するように心掛けています。「身体が資本」と言いますし、ここは大事にしていきたいですね。

仕事とプライベートの切り分け

私の場合は、なるべく切り替えができるようにプライベートの部屋と仕事部屋を分けています。プログラミングをやっていると、ついつい仕事とプライベートの切り分けをせずにやってしまいます。 リモートワークになってからそれが更に強くなってしまったようなので、家族との時間と仕事の時間をしっかり分けて対応できるようにしていかないといけないですね。

リモートワークはやってみないとわからない

３ヶ月リモートワークをやってみた感想としては、思いの外会社に出社しているのと変わらないです。（個人差はあると思います） 受け持っている業務に集中ができるので、むしろメリットが多くあると思います。ただし、上記に上げたような弊害もあるので、発生するトラブルとどう付き合っていくのか？という問題解決能力が重要になってくるのではないでしょうか。周りの仲間達とのコミュニケーションをしっかり取りながら進めていけば、きっとどの問題も解決していけると思います。読者の皆さんが所属する会社が許してもらえるようでしたら、是非リモートワークに挑戦してみてください！

今回のポストを読んで頂いて、リモートワークというものに対する理解が一人でも深まってくれたら嬉しい限りです。 そんな弊社もエンジニアを募集しています。リモートワークで働くエンジニアの方も募集していますので、リモート仲間募集中です。我こそは！という方がいらっしゃいましたら、是非エントリーしてください。

Web開発チームの安達です。

先日ブログでアナウンスさせていただいた「お肉を食べながらScalaのコードレビューする会」ですが、たくさんの方にご応募頂き、無事に開催することができました。今回は東京(5/14)と大阪(5/21)で開催したコードレビュー会の様子をレポートしたいと思います。

会場の様子

まずは各会場の様子からお伝えします。東京は5/14に、弊社東京オフィス近くのカーサ カステリーニさんというイタリア料理のお店で開催しました。普段から社員に人気のお店ですが、今回は「お肉多めのコース」でしっかりお肉を食べました。

大阪は5/21、梅田のmeat kitchen SAKAMOTOさんという焼肉屋さんで開催しました。せっかくテレビ付きの個室を予約したのですが、HDMIケーブル忘れてしまうというトラブルがありました。しかしお肉を焼きながらだとレビューしづらいという知見も得ることができました。

東京からすぶた職人も来ました。(参照: AWSのためのsbtプラグインを作ってみた)

盛り上がったコードレビュー

今回の課題は「MyList型を実装してみましょう」でした。スタックオーバーフローを回避するために末尾再帰を意識した実装、実装スタイルの違い、色々な解答が出揃っていたので盛り上がりました。中でも盛り上がった話題をピックアップしてご紹介します。

withFilterの実装

両会場でもっとも盛り上がったのが、withFilterの実装です。 出題の意図としては、filterの後にmapやflatMapなどの処理が続く場合に中間リストの生成を行わないようにして計算効率を上げるためです。例えば、

MyList(1, 2, 3, 4).filter(_ > 2).map(_ * 2)

のような処理を書いたとき、filter(_ > 2)をした後に一度MyList(3, 4)という中間リストが生成されてしまいます。

しかしListのwithFilterを使うことで、中間リストの生成を避けることができます。ではどのように実装すれば良いのでしょうか？

と、その前に。申し訳ないのですが、実はMyListのこの問題には不備があったとも言えなくないです。本家Scala(2.11)のコードと比較してみましょう。

こちらがScalaのwithFilter

def withFilter(p: A => Boolean): FilterMonadic[A, Repr] = new WithFilter(p)

こちらが課題のwithFilter

def withFilter(p: A => Boolean): MyList[A]

どうやら、本家のwithFilterはFilterMonadicという型を継承したWithFilterという型を返しているようですね。一方、お肉を食べる会の課題では返り値の型がMyList[A]型になってますね。確かに、中間リストが生成されないようにするには、mapやflatMap内でフィルタの関数p: A => Booleanを評価する必要がありそうで、これを行うためには新しい型を用意し、改めてmapやflatMapを実装する必要がありそうです。

参加者の方にはこのwithFilterをあれこれ手をつくして実装していただき、いろいろな解答が揃いました。 大きく分けて3パターンの実装がありましたので、それぞれ紹介します。

1. WithFilter型を用意するパターン

まずは王道の問題をねじ曲げるパターンです。WithFilter型を用意して、withFilterの返り値をWithFilter型にすると光が見えてきます。

解答例をご紹介します。

foldRightでリストを走査するときにフィルタリングを行っていますね。このような実装によって中間リストの生成を避けることができます。

2. MyListを継承した型を用意するパターン

MyCons[A], MyNil以外に、もう一つMyList[+A]を継承した型を用意するパターンもありました。 例として、MyFilteredという型を用意された解答をご紹介します。

この解答例では、map/flatMap/withFilterメソッドの実装でパターンマッチを使ってMyFiltered型の場合の処理を分けていますね。

3. 無名クラスを用意するパターン

withFilterメソッド内で無名クラスを定義し、map/flatMap/filter/withFilterをオーバライドするという実装をされた方も１人おられました。

実装はこのようになっていました。

この解答も問題のシグネチャを変更せずに、中間リストの生成を避けることができていますね。

名前の付け方

こちらも両会場でも盛り上がった話題は、メソッド内のメソッドにどんな名前つけますか？という話題でした。 再帰的な処理を末尾再帰で書くためにメソッド内にメソッドを定義することがあると思います。例えば、このような場合です。

みなさんはどんな名前を付けますか？お肉会に参加された方からは、

foldLeft0 (メソッド名の末尾に0をつける)

go

loop

といった名前が挙がってきました。色んな名前の付け方があっておもしろいですね。

startsWithの実装

startsWithは、引数で受け取ったリストがそのリストの接頭辞になっているかどうかを真偽値で返すメソッドです。ほとんどの方は次のようなタプル2(ペア)のパターンマッチを駆使した実装をされていました。

しかし、MyListにzipとforAllというメソッドを実装し、それを用いてstartsWithを実装された方がいました。まずは簡単にzipとforAllについて説明をします。

zip

zip[B](other: MyList[B]): MyList[(A, B)]は引数で受け取ったリストと同じ位置の要素をペアにした新しいリストを返すメソッドです。

例えば、MyList(1, 2, 3).zip(MyList("a", "b", "c"))はMyList((1, "a"), (2, "b"), (3, "c"))を返します。

forAll

forall(p: A => Boolean): Booleanは、リストのすべての要素が条件pを満たすかどうかを真偽値で返すメソッドです。

例えば、MyList(1, 2, 3).forAll(_ > 0)はtrueを返します。

startsWith

zipとforAllを用いてstartsWithを実装するとこのような実装になります。

左傾化

今回のようなMyListのメソッドを実装する課題のほとんどはfoldLeftを使って実装できますよ、という話が挙がってきました。 こちらの記事「scala を左傾化させる話」を参加者の間で共有し、もくもくと読む時間もありました。(関連ツイート)

解答例でもfoldRightを多用していますが、foldRightすらfoldLeftで実装が可能というお話でした。

まとめ

今回、東京・大阪会場ともに時間いっぱいScalaの話題で盛り上がり、色々な意見や情報交換ができました。今後またこのような学びの多い機会を設けたいと考えていますので、みなさんの参加を楽しみにお待ちしております。