v-htmlにscopedでcssをあてる
例えば以下のようなデータが渡されてきて、それをそのままHTMLとして解釈して表示したいとします。
contents = [ '<div>ふがふが</div>', '<div><a href="hogehoge.poriweb.com">リンクはこちら</a></div>' ]
データを受ける側が下記のようになっているとします。
<div class="contents"> <span v-for="(content, i) in contents" :key="i" v-html="content" /> </div>
この時、aタグの色を red にしたいとします。
<a href="hogehoge.poriweb.com" style="color: red">リンクはこちら</a> とすれば色を変えることは可能ですが、v-htmlに渡す content にサニタイズを入れているとaタグにstyle属性は含まれていませんのでこの書き方は好ましくないです。(できません)
解決方法
ディープセレクタを使用すれば良いです。
ディープセレクタは親コンポーネントと子コンポーネントのセレクタを繋いで外側からCSSを適用できるようにする方法です。
v-html でもディープセレクタでcssを適用することができます。
<style scoped> .contents >>> a { color: red; } </style>
ちなみにscssの場合
<style lang="scss" scoped> .contents /deep/ a { color: red; } </style>
以上、備忘録です。
Nuxt.jsでビルド後にenvを差し替えたい時
Nuxt.jsを使ってspa modeでWebアプリケーションを構築しています。
local/productionなど環境による変数(例えばAPIのURLなど)は通常build時に自動で切り替わるように設定を行うと思いますが、デプロイ手順の都合で後からENVを差し替えたい場合がありました。（デプロイ手順の都合: ステージングのdockerイメージをそのまま本番に載せるため）
そんな時はheadのsrcで静的ファイルのenv.jsを読み込むようにして、グローバルな定数を定義し、axiosのbaseUrl等はそこから参照するようにします。
手順例
- staticディレクトリにenv.jsを用意
- nuxt.config.jsonのheadにscript: [{ src: '/env.js' }]を記述
- pluginsのaxios.jsでbaseURLを定義$axios.defaults.baseURL = env.jsの定数
const BASE_URL = 'http://localhost:8000'
head: { title: 'hoge', ... script: [ { src: '/env.js' } ] },
export default function ({ app, redirect }) { app.$axios.defaults.baseURL = BASE_URL }
build後、dist/env.jsを差し替えても問題なく動作します。
あくまで静的ファイルとして配置されるだけなので、サーバー側で差し替えた時にクライアント側のブラウザは画面更新を行わない限りは当然前の状態のままになります。
以上、小ネタでした。
Gunma.web ＜カイゼンジャーニー＞に参加しました
gunmaweb カイゼンジャーニーに参加しました。
gunma.webは群馬のコミュニティで、私も昨年からお世話になっています。
今回はカイゼンジャーニーの著者、市谷さん、新井さんとカイゼンを実践している ジャーニーズ 渡部さんの三名に登壇していただきました。
以下は主に発表内容となっていますがところどころ私の所感が含まれていますので内容については各発表スライドを参照願います。
新井さん
自身の経験をカイゼンジャーニー本書を抜粋しながら、失敗と成功を挙げる形で発表をしていただきました。
まず三人くらいのチームで最初は朝会はどうやるのかから始めたそうです。
課題を焦点に合わせる、一般用語を使うといったところが成功として挙げられています。たしかに、アジャイルを取り入れようとした時に手段が優先になることやプラクティスを実践することに目がいきがちです。自分も用語ばっかり達者にならないように本質的な部分に焦点を当てていきたいです。
次に講演をやっていった中で失敗として挙げられている「いつも同じメンバー」については広げていくにはやはり期間が必要ということでした。なぜやり方を変えるのかという問いに対してはバリューストリームマップを作成したのが大きかったということでした。1対1ではなく、みんな対問題になる構造ができるのが良いようです。
そして社外との関わりへと広げていったそうです。この話の中では新メンバーについてのモブプログラミングへの言及が印象的でした。チームの成長と新メンバーの育成が同時にできる。モブワークで採用を一人ではなく複数人で行なったといったプラクティスが面白いと思い活用できそうだと感じました。また、カイゼンジャーニー本編でも出てきますが、新メンバーを入れた時の星取表（チームメンバー全員のスキルセットの可視化）の効果はかなり高そうだなと感じました。私自身も過去プロジェクトの途中で参画したメンバーがどのような分野が得意で苦手かわからず、期待のズレが発生することがありました。そういった時に星取表で得意なことを可視化するプラクティスはとても有効だと思います。
まとめとして、諦めるのも人生、気づいた時に行動を起こすのも人生だけど、自らの意思で決めたその時に起こる波紋が何かを産むということで、まず自分からやっていくことで気づいたら越境している組織になったということでした。まず自分から。
市谷さん
スライド公開されていないようなので（見つけられなかったので）、私自身の感想が（あまり）入らないように書きたいと思います。
まさにカイゼンジャーニー江島と重なる部分の多い発表をしていただきました。（カイゼンジャーニーのあとがきの江島くんはだれなのか。に書いてある通り、完全にモデルが市谷さんということではないそうです。）
発表の内容は現場や職場で直面する問題は周りの人を巻き込まなければいけない場面がやってくるという話から始まりました。
最初は環境にせいにしていた部分があったそうです。（隣の芝は青い）しかし、プロジェクトの炎上という「事件」があってこの繰り返しでは何も良いことがないという問題意識を感じ始めたそうです。救世主を待ち続けても状況は変わらない→自分がなんとかするしかない。ということでまず会社の中で閉じていていては解決策は見つからないので、境界の外に出る。結果がどうなるかわからないが自分のいる環境をよりよくする活動をしたいという気持ちで越境したそうです。 しかし、気づいた人しか越境しない「ぼっち」で周りを巻き込めない、長続きしない、一人でやると心が折れていきます。
あるイベントの時に帰り道に一緒に帰る人がいて、同じ方向に向き合うことができる仲間ができたそうです。同じ方向に向ける仲間、つまりカイゼンジャーニーの「二人目の存在」ができるということです。（カイゼンジャーニーの中で似たような話が出てきますね！イベントの帰り道は数日後日常に戻る前の向き合う時間として重要で、それは私もよく感じています。）
二人目の存在は大きく「最悪この人がいればいい」という心の安心感があります。例えば社内でイベントを起こすにしても一人じゃないことの心の余裕は大きいものです。
二人で何をやったか。
勉強会などを企画するコミュニティを作ったそうです。活動を続けるうち2人が100人、100人が5000人になっていったそうです。人が集まればいろんな知見が集まるので閉じる必要はない、広げようとDevLove（https://devlove.doorkeeper.jp/）というコミュニティを立ち上げました。これは社内で越境したい、会社から越境したいという人たちが集まる外側にある集合場所とのことです。
発表の中で視野と視座についても触れられていました。
高さと広さの間で観ること。視野を広く、視座を高く、よりも行き来できることが大事というのはとても印象に残りました。
最後に境界とはなんなのかについて。自分がこれまでに経験したことによる世界の捉え方です。カイゼンジャーニーにも出てくる言葉である「あなたは何をしている人なのか」といった問いを考えることで何か始められるのではないでしょうか。いつだって始めるのは自分から。
ちなみに質問の中で「二人目はなんとなくこの人だろうなというのがあったのですか？」という問いに対して、「本当にたまたま」ということでした。二人目の存在は身近にいるものですね。
渡部さん
ジャーニーズ としてうまくいった越境とうまくいかなかった越境の体験談を発表していただきました。
うまくいかなかった越境ではプロダクトマネージャーとして、アプリ開発をリリースまで走り抜けたが、終わってみて良いプロジェクトだったのか考えた時、うまくいってなかったという振り返りをしたそうです。利益なし、資産なし、JOY（開発の面白さ）なし、リリースで力尽きて運用がなぁなぁに・・・
Why なぜそうなってしまったのか。みんなの目的、目標がバラバラで自分中心のマネジメント、Whyがない人もいたなど。こういった状況を自分自身諦めてしまって進めたのが大きいということでした。
次にうまくいった越境として、モブプロ経由で出会ったスクラム。これを始めたそうです。
まず一人で始めて良いプラクティスであることを体感、チームのマネージャーにスクラムの必要性を説いたそうです。最初は半分くらいの人でスクラムをやってみようとなり、やってみてこれは良いとなりチーム全体に広がっていった。そうこうしている時に渡部さんはカイゼンジャーニーと出会って、今までの活動に自身が持て、次のチームビルディングのアイデアが出てきたそうです。
うまくいった越境とうまくいかなかった越境の大きな違いは「対話」で、対話は思いが可視化されるもの。渡部さんはいろんなプラクティスがあるが、それは対話をさせるためのものではないかと捉えているようです。
プロジェクトがうまくいく場合、チームの対話、コミュニケーションが活発であることがよくあります。対話の重要性を再認識しました。
渡部さんもまずは一人で始めるところからスタートしています。やはり、まず自分から。ということです。
通常LT
招待講演ののち、Gunma.web恒例の通常LTがありました。
- @kanayannet さん
問題が発生した時にどんな報告をするかといった事例を挙げた、コミュニケーションの取り方についての発表でした。
ジオングの紹介もしていました（？）
- @TsukasaGr さん（ウエノさん）
自分がやってきたこと、これからやることについての発表でした。
失敗談からWhyについての深堀、カイゼンジャーニーを読んで現状をひとつウエノ男になったのでカイゼンしていこうという内容でした。
- @noviiroさん
飛び込みLTで近況報告をしていて、店員をされているおいしい日本酒のお店で三次会をやらせていただきました。おいしかったです。
最後に
少し自分が感じたことも書きすぎた気もしますが以上が今回のイベントのレポになります。
記事を書いている現在まだ電車に乗っていて、推敲されてない文章がありますが、気持ちをアウトプットしたいと、ブログを書きました。
カイゼンジャーニーを読んだ時から衝撃を受けて、本日お話を伺って大変勉強になりました。自分自身、まだまだ越境できるなと感じているので、身の回りからどんどんカイゼンしていきたいと思います。まず自分からですね。
個人メールをAWS WorkMailにしてみた
独自ドメインで個人用のメールアドレスを取得したかったので、AWS WorkMailを使ってみました。
利用開始の基本的な手順はawsの公式やweb上にありますので簡単に紹介して、気になったところを備忘録的に記述します。
選定理由
- 管理するものを分散させずできるだけまとめたかった
- Route53で取ったドメインで簡単にメールを使いたかった
WorkMailの利用開始の流れ
AWS管理コンソールより
ビジネスの生産性のWorkMailを選択します。
2018/10/01時点での対応リージョンは下記になります。とりあえずメールが使えればOKという場合は
Quick setupを選択します。エイリアスを設定してしばらく待ちます。
作成されたエイリアス名を選択します。
メニューより
Domainsを開き、Add dmainを選択します。Route53で取得したドメインを入力します。
Route53にTXT, MX, CNAMEレコードを追加します。(step1,2両方)
完了するとステータスがVerifiedになります。メニューより
usersを開きCreate Userにてユーザーを作成します。メニュー
Organization settingsにWeb ApplicationのURLがあるのでそこから作成したユーザーでログインするとweb版のWorkMailが使えるようになります。
Route53について
ドメイン取得後、 Hosted Zone の対象ドメインを選択して Create Record Set を順番に行なっていきます。
WorkMailで表示されているTXT, MX, CNAMEをコピペして登録していきます。
name の自分のドメイン部分は入力する必要がなく最初から表示されているので、ドメイン手前までをコピーして貼り付けるようにします。
作成されたメールを外部アプリで使う
とりあえずthunderbirdで使えるようにしました。
受信サーバーと送信サーバーについては下記に書かれています。
たとえば米国東部 (バージニア北部)のリージョンであれば、
- 受信サーバー
- imap.mail.us-east-1.awsapps.com
- port: 993
- 送信サーバー
- smtp.mail.us-east-1.awsapps.com
- port: 465
- ユーザー
- 送信受信共にメールアドレスと同じ
となります。
所感
比較的すんなりメールを使うことができるようになりました。 料金は安くもない(2018/10/01現在1user月額4USD)ですが管理するサービスが分散しないでノーメンテで楽というのが個人的には大きいです。 AmazonSNSによる連携も比較的楽にできそうなのでそこも良いです。
参考
ブログ始めました ~アウトプット大事!~
群馬在住のSE、poriです。 群馬にいますが都内の案件を中心に仕事をしています。
アウトプットの重要性について
技術的なことを学ぶ時って本を読んだり、勉強会で公演を聞いたりインプットを行うことが多いと思うのですが、それを溜め込んでいると実はわかっている気になっているだけで実は腹落ちしていないことがあります。
備忘録として乱雑に書かれたメモを後から見て理解できなかったり、いざ人に説明しようとすると要点のまとまらない話になってしまったり...。
自分の中だけで完結せず、整理してアウトプットをしておくとすっと入ってくるものです。
などなど。
一つ目と二つ目については、例え備忘録的なものであったとしても人に読まれることを意識して記事を書いた方が身になります。
また、学習を行なった後アウトプットするということを決めておけば、自身の学習の目標達成度を客観的に見ることができてKPTを明確にしやすくなるかと思います。
学習を習慣化させること、その取り組みの中にアウトプットを含めることでより効果が高まります。
ブログの内容について
上記の理由から、アウトプットを目的としたブログを書いていきたいと思います。
Twitterは以前から利用していましたが、どちらかというとコミュニケーション目的でした。
また、勉強会での発表や講師役などは頻度が高くないため、もう少し短期的なスパンでアウトプットができるようにと思い、blogもやっていこうと思います。
主に技術系の投稿中心になるかと思いますが、ゆるい内容も書いていきたいです。
短いエントリーとなりましたが、よろしくお願いいたします。
