Windows+WSL環境でdocker-compose upして開発環境を作るためにすること

gitの改行コード自動変換を切る

> git config --global core.autoCRLF false

勝手に改行コードが変換されてしまうので止める。

wsl側でdockerを使えるようにする

• wsl・windows両方にdockerをインストールする
• docker for windowの「Expose daemon on tcp://localhost:2375 without TLS」にチェックを入れる
• export DOCKER_HOST='tcp://0.0.0.0:2375' を.bashrcなどに書き込む

wsl側のdockerをクライアントとして、docker for windowsのサービスを扱うイメージ。

docker for windowsのDNSサーバを設定する

`8.8.8.8などにする

結構タイムアウトするので。

ドライブのマウント設定

ドライブのマウントはデフォルトだと/mnt/c/のようになるが、これだとdocker-composeのボリュームマウントのパスがうまく解決できない。

[automount]
enabled = true
root = /
options = "metadata,umask=22,fmask=11"
mountFsTab = false

/etc/wsl.confを上記のようにすると/c/のようにマウントされ、これだとdocker-composeのボリュームマウントがうまくいく。

FirebaseとVue.jsでMicroFrontendsした。

昨年7月に開催された Microservices Meetup vol.7 (Micro Frontends)

に参加して、「FirebaseをバックエンドにしてMicroFrontendsやったら良さそう」という事を思っていたのですが何もせず、年末になって暇になったのと、たまたま知人から上手くいきそうな話を頂いたので、試しに実装してみました。

何を作ったか

Demo

github.com

レビューの投稿・一覧だけを責務としたサービスを作りました。 「WordPressでメディアを運営していて、独自のレビューシステムを導入したいが、WordPressを拡張したくはない or 出来ないケース」を想定しています。

<script src="https://unpkg.com/vue"></script>
<script src="https://anochick-revue.firebaseapp.com/revue-components.min.js"></script>
<revue-form subject-id='demo'></revue-form>
<revue-list subject-id='demo'></revue-list>

上記のタグを埋め込むだけで、「レビュー投稿フォーム」と「レビュー一覧」が利用できます。

記事そのものについてはこのサービスでは扱わず、記事IDをコンポーネントに与えて利用します。

subject-idは記事ID等の任意の文字列を想定していて、記事毎にレビューコメントをつけることが出来ます。

Firebase Authenticationを利用しており、ドメインの許可が必要な為、用意したデモサイトとjsfiddleでしか動きません。（もちろん設定すれば他サイトでも動くようになります。）

MicroFrontends

マイクロフロントエンドとは、平たく言うと、マイクロサービスのAPIを、HTTPやRPC等のエンドポイントではなく、DOMの一要素として提供する事です。

Micro Frontends - extending the microservice idea to frontend development

今回は、バックエンドにFirebaseを採用しましたが、APIはWebComponentsとして提供しているため、バックエンドの実装を意識せずにサービスを利用することが出来ます。

構成・実装

システム構成は↑の通りです。

Webコンポーネントのソースコードは、FirebaseHostingでホスティングしています。

WebComponentsの実装には、Vue.js、@vue/web-component-wrapperを利用しています。

作ってみて

ユーザデータの作成にCloudFunctionを使っていることもあり、待ち時間がやや長く、地味に体験が悪くなってしまいました。 とはいえ、手軽に、サーバレスでMicroFrontendsなサービスが提供出来るのはなかなかおもしろいと思いました。

またなんか思いついたら作ります。

関連のある・参考にした記事

Vue CLI v3 を利用して、あらゆるサイトに埋め込める Web Component ベースの Qiita スライドビューアーを開発した話 - Qiita

【改訂版】 Firebase Cloud Firestore rules tips

Micro Frontends - extending the microservice idea to frontend development

冬休みなので変なものを作った

前々からあったら便利かなぁと思っていたものを作りました。

github.com

Scubaというものです。 FirebaseとNuxt.jsでさっと作りました。 Webサービスですが、グループウェア的な位置づけです。

↑がWebhook編集画面です。

Webhookを作成すると、cloudfunctionsのURLが発行されます。 そのURLのリクエストに対応する処理を、ブラウザ上でいじれるというわけです。

主な用途

Slackのコマンドやボット作成

Slash CommandsやEventSubscriptions等、イベント発生時に特定のURLを叩くような仕組みで有効です。 Slackの場合だと、そのURLを使用するために、リクエストに含まれるチャレンジ文字列をレスポンスに含める挙動にする必要があります。 デプロイする必要がないので、こういった一時的にほしい実装とかを手軽に入れられて良いです。

res.send(req.body.challenge);

とするだけで検証を通す事ができて楽です。

Webhookを使ったサービス間連携の中間に入れる

サービスで提供されているWebhook連携をそのまま使うだけじゃ満足できない場合って有ると思います。 「○○の場合だけ通知したい」とか「文章フォーマットをカスタマイズしたい」とか。 そういうときに、Scuba Webhook でリクエストを受け、フィルタリング・整形をして、他サービスのWebhookURLを叩く。 のように、Webhook連携をちょっとカスタマイズ刷ることができます。

Form

Scubaには、Webhookとは別にFormという機能をつけました。 これは、平たく言うと「WebAPIをフォームとして提供する仕組み」です。

こんな感じで、アクセストークン・チャンネル名・メッセージを入力して送信すれば、指定チャンネルにメッセージを投稿できるようになります。

こういったフォームを、プログラムを書くことなく作る事ができます。

「変数」がフォームで指定できる値のことで、この変数が、URL・パラメータに展開されて、リクエストを飛ばします。

以上です

どちらもかなり実験的なものなので、とっても謎な感じになりました。 次はもう少し人に理解してもらえるものを作ろうと思いました。

LINEスタンプをSlackのEmojiとして登録する

www.youtube.com

オトッペ可愛い。みんなかわいい。是非見て。

この記事は

masawada Advent Calendar 2018 - Adventar のために書きました。 masawadaにはお会いしたことありません。

前日の記事は↓

■ - パピッター

です。

本題

僕たちはしばしばSlackにLINEスタンプのサムネイル画像のURLを貼って楽しんでいます。

linestamp

store.line.me

見ての通り、LINE STOREにあるスタンプのプレビュー画像は、なんの認証もかかっていません。 そのため、このように行儀の悪い使い方が出来ます。

でも、いちいちLINE STOREから引っ張ってくるのは面倒なので、Emojiとして登録してしまいましょう。

で、こんな感じのものを作った。

1. Slashコマンドで、LINE STOREを検索する
2. 気になるスタンプグループ(product)を選択する
3. Emojiにしたいスタンプを選択する

これだけでLINEのスタンプがSlackのEmojiになります。

あとは、LINEスタンプは絵文字にしてしまうと見辛い物が多いので、/stampコマンドも用意しました。

こうすると

こうなります。

tech.grooves.com Grooves開発ブログさんの記事を参考にしました。

仕組み

Slack以外にはFirebaseのCloudFunctionsしか使っていません。 LINE STOREの検索、要素抽出にはpuppeteerを使いました。

Emoji登録には github.com こちらを使いました。

でまぁ、作りはしたんですが、 Emojiを登録するところとか、結構厳しい実装ですし、 そこそこモラルに欠ける感あるので、「是非使ってください！！」とは言いづらい感じになりました。

ですが、下記のような知見が得られたので良かったです。

• SlackのSlack Commandは3000msタイムアウトの壁がしんどいと思ってたけれど,response_urlを使えば問題にはならない
• Cloud Functionsで普通にpuppeteerが使える
• SlackのEmoji登録API,あるには有るけどブラウザからログインしてトークンを抜いて使う必要がある
• Interactive messagesがなかなかおもしろい

もうちょっとコード綺麗にして公開したい気持ちが0.1%程度はあるのですが、 なかなかキワモノ感でちゃったのでそんなやる気は出ない気がしています。

以上です。ありがとうございました

store.line.me

記事に出てきたLINEスタンプはこちら。

2018年の振り返り

NHK Eテレで好評放送中の子供向け教育番組「オトッペ」の新ED曲"バラバラバンバ"が配信開始しました。

つい電車の中で口ずさんでしまうほどとても中毒性が高くて良い曲なので、是非リッスン聞けけ！

それはそうと、今年の振り返りをしたいと思います。

沢山の人と関わった

昨年の10月に転職をして、今年の10月にもまた転職をしました。 環境の変化が激しく、たくさんの素敵な方との出会いがありました。 ねおりんもその中の一人で、家で一緒にゲーム開発をしたりしました。

Speee在職中は、全くと行っていいほどプライベートで人と関わらない生活をしていたのですが、 転職して、一年でだいぶライフスタイルが変わったように思います。

来年はねおりんハウスに遊びに行くことを目標としたいと思います。

健康ではなかった

あまり健康ではありませんでした。 多分ここ10年でみて一番不健康だったと思います。 扁桃炎が3回、一番ひどいので完治に1ヶ月を要しました。 抗生物質を頂いていたのですが、なかなか治らなく、このままだとRubyKaigiに行けなくなる！ということで薬を倍量処方していただき、無理やり抑え込みました。

現在もなんだかよくわからない肩の痛みに悩まされており、起きるのも一苦労な状況です。

不健康が1週間以上続くと、メンタルにも大きな影響がでるので、健康の大切さを改めて感じるようになった1年でした。

知識が増えた

転職も含めて、半年に1回のペースでプロジェクトが変わったこともあり、幅広く新しい技術知識を得ることが出来ました。 また、プロジェクトの形態も様々で、いろいろな事情があるんだなぁといい勉強になりました。

発信が減った

ツイッター・ブログを書く頻度がめちゃ減りました。 ブログなんかだと、去年、一昨年は月2本のペースで書いていたのですが、 今年はこの記事を入れてトータルで6本。 ツイートも昔と比べるとかなり頻度が下がったように思います。 その分Slackの利用は増えたのですが、完全パブリックな発信は確実に減っています。 あとはちょっと違うんですが、プライベートでの開発と公開も結構減りました。

知識がこぼれ落ちていく感覚

私はそんなに記憶力が良い方ではないので、使わない知識はどんどん忘れていきます。 直近の業務合わせて最適化しているので、業務に支障は無いはずなのですが、 なんだかもったいないと思うことが増えました。 デジタルマーケティング領域の知識とか、今の職場だとかなり役に立つのですが、1年もゲーム業界に居るとかなりの量の知識が落ちます。

2019年はどうしたいか

健康第一

ほんとこれ。 特に今、リモートワークなのもあって、下手すると大きく崩れそうな気がしています。 健全な生活を心がけます。

文章を書いていく

ブログ記事とか、積極的に書いてきます。 技術書展とか、本の執筆とかも機会があればやりたいです。

そんなかんじです。具体的な目標に落とし込むかどうかはまたの機会に。

おんやど恵で開発合宿した

10月の20,21日に元同僚の人たちと4人で開発合宿に行きました。

楽しかったです。 宿泊先は、「おんやど恵」です。

www.onyadomegumi.co.jp

20日の朝、4人で東京駅から電車に乗って湯河原まで行きました。 私は18,19日と会社の合宿があったので、この時点で体力は3割ぐらいでした。

お昼ご飯は海鮮丼でした。わさびがめちゃ辛かったです。

おんやど恵では、宿泊施設とはべつに、会議室も借りました。 大きなプロジェクターも借りて、みんなでマリオパーティをしました。私は1回勝ちました。

夕食・朝食がありました。正直言うと、割引プランなのでそこまで期待していなかったのですが、とても美味しかったです。

旅館にありがちなパズルをたくさんやりました。半端なく難しいです。

ちなみに、開発合宿なので、何かの開発をするのが主目的で、 私は「firebaseでmicro frontendsっぽいことする」 というテーマだったのですが、前日までの合宿でヘトヘトだったので結構寝ていました。

次行く時は万全の体制で挑みたいと思います。

後輩とリモート開発配信した

なんでやったのか

動画配信とかやりたかったからです

作ったもの

まだ未完成だったりリポジトリにCredentialsがはいりっぱなしだったりするのでソースコードの公開はまだですが、 ざっくりいうと tech.speee.jp のリメイクです。 そこそこ評判は良かったのですが、スコープ制御がザルな所が気に食わなくて開発モチベーションが上がらず、何もしないでいたのですが、なんか良さそうな実装案がでたので、今回はそれの開発をしました。

後輩について

twitter.com

オタク。 前職の後輩で、歳は4つぐらい下。私と同時期に転職、現職も会社は違うが私と同業種。オタク。

21時、配信準備をする

当初は、macでスクリーンキャプチャをする感じで,OBSというソフトウェアを使って動画撮影だけしようと思っていたのですが、通話音のとり方がよくわからなくて、sowndflowerというものも試してみたりもしたのですが、結局うまく行かず断念しました。このあたり詳しくないので誰か教えてください。

通話自体はGoogleハングアウトで行っており、ちょっと調べてみたらGoogleハングアウトやりとりがそのままYouTubeに配信出来たので、「それじゃあもう配信しちゃって、あとでアーカイブされた動画を編集したらいいか」ということになり、そのままGoogleハングアウトをYouTubeに配信していました。

22時、配信開始

配信を開始し、まずディスカッションをはじめました。 といっても、何を作るかとざっくりとした仕様についての方針を決めたぐらいで、 その後は雑に設計議論・調査・実装をしていました。 一度配信を止め休憩をはさみましたが、基本的にはずっと作業をしていました。 明け方の4時頃になって、脳みそが全然働かなくなったのを感じたのでそこで配信を止めました。

良かったこと

進捗がよい・相談のしやすさ

そもそもリモートで互いの画面を配信しつつ、通話で共同開発するっていう体験をあまりしたことがなかったのですが、 二人で作業していると、解決までが速いように感じました。

常につながっているので、会話コネクションの開始・終了が無いように感じられる事が相談の障壁を下げていて、その結果として問題解決スピードが早くなったんじゃないかと思いました。

話すことはたくさんある

ゲーム実況や雑談は、何を話したら良いかわからなくなることが有ると思うんですが、 開発配信となると、ものを作る為に必然的に議論が発生するので、「面白いこと言わなきゃ」とか考える必要がなく、ただ作ることだけ考えていれば良いというのはやりやすかったです。

なので、音声コンテンツとしては結構可能性を感じました（万人が面白いと感じるかは別として）

良くなかったこと

観てて面白く無さそう

音声はいいとして、画面が全然映えないです。 ゲーム開発とかしたらまた違うのかなと思いました。

観せられないものがたくさん

開発作業って、結構観せられない画面多いなぁと思いました。 - Webブラウザ(GitHubのprivateリポジトリとか) - ターミナル(なにがでるかわからん) - 動作画面(作るものによっては問題無さそうだけど今回はSlackだったのでウィンドウ共有は厳しい) - エディタ(うっかりenvファイルを開く危険性)

というような感じで、安心して映せるウィンドウが無くて、今回の配信では 「envファイルをAtomで絶対に開かないという強い気持ち」だけを忘れないようにAtomの画面を共有していたのが９割ぐらいでした。

コーディング配信をする場合は

• 動作画面が常に見せられるものを作る
• Credentialsの扱いをちょっと工夫してティストエディタも常に見せられる
• 開発環境を別に用意する

とかすると良さそうと思いました。

すごい疲れる

ゲームの実況配信と比べて、すごい疲れるのと、疲れた時の脳死感が結構厳しい感じになります。 トイレに行くとかはありましたが、ちゃんと配信を中断して休憩時間を取ったのは、12時ごろの１回だけだったので、 単純にうまく休憩が取れてなかったのかもしれません。

もしかしたら３人でやったらもう少し余裕ができるかも。

これどうやって動画投稿するんだ

約５時間の動画が出来たわけですが、検索履歴とかが映っていたりもするため、そのままあげることは出来なくて、 かといってこれを編集するのもしんどいので、きっと今回の動画が世にでることは無いんじゃないかと思います。 「３０分程度の動画コンテンツとして仕上げる」ということについてはまだ全然考えきれていないので、もう少しこのまま開発配信をやっていこうと思います。

まとめ・次回配信に向けて

開発配信はすごく楽しかったです。色々知見が得られたのと、リモートペアプログラミングの可能性を感じました。

動画コンテンツを作るのって難しいなと思いました。ですがいずれはちゃんとした動画ファイルにして投稿出来るところまでやりたいです。

@miyachikは頻繁に関わっていたり、一番コンテキストが近いエンジニアなのでとてもやりやすかったです。 機会があればまたやろうと思います。

もちろん、それ以外の人ともやってみたいなと思います。 なので、僕と一緒に開発配信してみたい人、いらっしゃったら気軽に声かけていただければと思います。 開発スキルのレベル感は問わず、「プログラミングやったこと無い〜」って人でもそれはそれで面白いんじゃないかと思ってます。

追記：結婚相手も募集してます。