やまろぐはてな

yamanokuの技術メモとか戯言。真面目に見たり見なかったりしてください

「さくらインターネットのエンジニアは Vue.js をこんな風につかってます」レポート #さくらの夕べ

connpass.com 10/25(水)に、さくらインターネットが主催の「さくらの夕べ」にてVue.jsの業務内活用についての発表がありましたのでそれの個人的まとめです。こういう話聞くと久々にやるかみたいなモチベになります。(はやくやれ)

第1部「はじめてのビュウ」

www.slideshare.net

さくらクラウドの料金シミュレーションをVue.jsで作った https://cloud.sakura.ad.jp/payment/simulation/

経緯

もとはAngular1系。UIはそのままで一部のみ変更。URLでの記憶機能や時間割計算も対応できるようにした。

課題

メンテコストがキツイ。フロントと何故かバックエンドのダブルメンテ。

Vueの採用理由:

  1. 覚えることが少ない。久しぶりに手をいれるときにも思い出しやすいんじゃないだろうか
  2. 公式のライブラリでまかなえるので継続メンテが期待。vue-routerとかVuexなど
  3. 日本語情報が充実している。Vue.jsの公式ガイドは親切丁寧でだいたい分かる https://jp.vuejs.org/index.html
  4. 人気と勢いが凄いのでメンテする人は後続ができる期待

実装の時に気をつけること

構成、命名規則について

コンポーネントの構成を決める際に、テストしづらい、使いまわせない、分割できないといったものにならないように気をつける ItemContainerという親を作るとItemGroupの場合はどっちが親?となる

<ItemGroup>
  <ItemContainer> <= こういった構成なら分からなくもないが単体だと分からない
    <Item />
    <Item />
  </ItemContainer>
</ItemGroup>

Catrgory、ItemListなどの的確な名前づけをした。親子関係と役割を想起しやすいようにしよう

<Category>
  <ItemList>
    <Item />
    <Item />
  </ItemList>
</Category>

ディレクトリ構成について

  • 単一では意味をなさない組み合わせではじめて意味をなす <components>
  • 単一で機能できるコンポーネント <layouts>
    • 関連するものはひとまとめにしておく
    • スタイルも一緒に梱包する
buttons
├─ AddFieldButton.vuw
├─ RemoveFieldButton.vue
└─ SaveButton.vue
bill
├─ bill.vue
└─ bill.scss

VuexでのStoreについて

Store構成 => コンポーネント内部だけで知っておくべきこと(タブの開閉)、全体として知っておきたいもの(合計金額)を洗い出していく。

アプリケーションが大きくなると見通しが悪いが、Vuexのmoduleで見通しをよくするようにしておく。

const moduleA = {
  state: { ... },
  mutations: { ... },
  actions: { ... },
  getters: { ... }
}

const moduleB = {
  state: { ... },
  mutations: { ... },
  actions: { ... }
}

const store = new Vuex.Store({
  modules: {
    a: moduleA,
    b: moduleB
  }
})

store.state.a // -> `moduleA` のステート
store.state.b // -> `moduleB` のステート

第2部「Vue.js 導入の経緯と実例紹介」

経緯

さくらインターネット上にはさまざまなwebサービスがあるが、実はフレームワークが乱立している問題があった(好きにやっていい裁量がある)

  • Angular
  • Vue
  • jQuery
  • prototype
  • ember

課題

  • 結果としてプロジェクトへの参入コストが増大している問題が起こる
    • 似たような機能開発でもフレームワーク毎に別の実装になったり、技術が分散され共有されにくい
    • いつの間にかフレームワーク使われてたけど知られてなかったのようなことが起きる
    • ほか学習コストや属人性について
  • フルスタックフレームワーク(Angular)を使うにしても開発のスタートを切るためには時間がいる
  • デファクト・スタンダードとなるものを選定する必要がある

Vue.jsの普及

そんな中、社内SlackにVue.jsを推す影響力のある人がおり、反応してみた。 実はウェブアクセラレータや幾つかの過去のプロダクトにはVue.jsが使用されていた模様。

何とかして良さそうなVue.jsを普及してみたい。が、実績についてはあまり無かった(ウェブアクセラレータくらい)。 そのため、社内での利用事例を増やすために小さいプロダクトからVue.jsを導入してみることにした。

実際に取り入れてみる

さくらインターネット20周年に際して、TOPページのリニューアル案件が立つ。そこで一部にVue.jsを導入してみることにした。

www.sakura.ad.jp

スライダー

https://gyazo.com/6fd8efd405d14355e133d4edb69525fe

Ajax読み取り箇所

https://gyazo.com/d0d00bb90171bb6137c17377c92d5547 Vue-resourceを使用。

Vue.jsでの制作実績

やってみた結果

  • デザイナーと協業しやすそう(シンタックスとして分かりやすい)
    • エンジニアとデザイナーが分業しやすい
    • ロジックとhtml、スタイル箇所がtemplete内で分けられるので棲み分けが良さそう
  • 導入スピードがダントツでよかった。
  • 日本語ドキュメントが充実している、プラグインが豊富なのも良い
  • CDNなどでソースに直接入れ込むことが出来るのですぐ使える https://gyazo.com/01764c33a12dbc94f2a7428f79b028b2
  • Vue.jsはあくまでもjQueryの置き換えになるわけではない。新たなロジックの書き方を知る必要はある
  • 2.5が出るまではTypeScriptの対応が未知数だった
  • 他のフレームワークも良い部分があるので、Vue.jsを使うなら「なんでVue.js使うんですか?」に答えられるようにする
  • 今後の開発において大きめのコントロールパネルでVue.jsを導入する予定

第3部 「とにかく楽してVue.jsでTypeScriptを使いたい」

ダーシノさん https://twitter.com/bc_rikko

  • さくらクラウドのネタ機能担当フロントエンジニア
  • Vue1.x系での2行Contributor

www.slideshare.net

静的型付ができることで最近話題になっている(ことにしてほしい)TypeScript。 Vue.jsでもせっかくなので使ってみたいと思ったけどVue2.4以前ではかなりつらいことが多かったのだが、Vue 2.5からTypeScript統合の改善がされ、だいぶ楽になったよという話。

今回はサーバーサイドエンジニアもメンテナンスができるように、ということで型定義がおそらく好まれているだろうことを推測し、TypeScriptを全面導入。

thisprops型推論ができて、class構文ベースの記述が以前は必要だったがそれがいらなくなるなど改善された箇所が多く、つらくなくなった。 jp.vuejs.org

便利なVue.js + TypeScript体験一式も配布。ありがたい。 github.com

第4部 NUXT.jsでウェブサイトを作れるのか?(未完)

ja.nuxtjs.org

Nuxt.js とはユニバーサルな Vue.js アプリケーションを構築するためのフレームワークです。

具体的には何ができるのか?

  • SPA
  • SSR
  • 静的サイトジェネレーター <= 個人的にコレを試したいと思っている

静的ジェネレーターの代替

を他にも検討しているが、Vue記法をつかいたいため、Nuxt.jsを推したい。

コマンドで切り替え可能

"scripts": {
  "dev": "nuxt",
  "build": "nuxt build",
  "start": "nuxt start",
  "generate": "nuxt generate"
}

SPAにする場合は --spa オプションを付与。

問題点

  • アプリのヘッダーやHTML属性はvue-metaを使わないと更新できない。
  • 新しいため、まだまだ知見が少ない

参考・関連URL

HTML5 Conference 2017 行ってきたよ

events.html5j.org

去年 → HTML5 Conference 2016 行ってきたよ - やまろぐはてな

自分用まとめです。結構長くなった。

続きを読む

backlog上で案件・進捗管理をしていた自分がGithubに触れてみた感想

転職してから業務管理ツールをサイボウズ(勤怠が主だったけど)→backlogに変わってずっと進捗管理をそこで行ってきた。2年くらいになるけど、Redmineとかには触れないでも、方向性とかやり方を模索しながらうまいこと立ち回ってきたように感じる。

そんな中こないだより弊社でもbacklogでは案件自体の管理、Github上で修正・ソース管理を分割していこうという流れが出来てきて実質2案件くらいの開発案件では行っている。自分も1つ案件に入ってきたのでGithub上で仕事している。そんな中で思ったこととか感想とかを書き綴ってみるなど。

案件の可視化に関しては圧倒的にbacklog優位

見やすさとか検索のしやすさであれば圧倒的にbacklogかなと思った。そりゃ案件管理ツールとGit連携サービスとを比較するのであれば酷なのではあるが、ガントチャートを見たり案件内でどういう課題が作られているか・進行しているか、などのディレクター、マネージャー、エンジニア、デザイナーなどの全員が案件の動きを見る面ではかなり強いなものなのだと感じる。

Github上でもマイルストーンやIssueを作ってあげたりwikiで詳細を書いてあげたり、backlog同様に1つのプロジェクト内で案件管理することは不可能なことではないしうまくやれる方法は模索できるとは思うが、それ相応の準備(勉強)とかがいると思うので、Githubを使って案件管理をしよう!というよく分かってない浅はかな思考をもつエンジニア・ディレクターが居たら首を締めてあげるのが人情というものです。

あと自分はGitの履歴を見る上でネットワークで図示されたのを見るのでbacklogのは割と分かりやすくてよいのだけれど、Githubはそこに行き着くまでが若干分かりづらいかなとも思った。見れるには見れるんだけど。

f:id:cardboarder:20170918011956g:plain

逆行して考える力の必要性

新しい案件が走る場合、まず要件定義なり客の要望などをしっかりと固めてあげて、そこからどういうものを作るかを明らかにするものだけど、それを完成するに辺り何が必要なのか、何をもってして完了と言えるのか、という部分を明確にしなければならない、というのがGithubでプロジェクトを進行していてわかった・感じたことだった。

GithubではIssue(課題)を立ててどういう機能を作っていくか・作ったときに出たバグを潰すかというのがあるが、Githubの仕様上、立てたIssueはCloseこそできるが完全に削除することができない(消すにはプロジェクト自体を削除するとかになる)のでバカスカバカスカ立てても結局精査する時間もあるので、Issueを立てるのは慎重にやる必要があると思う。

つまり課題を立てる上で、何をもってそれをプロジェクトやバグ修正の完結に向わせるか、それを完結させるために用いるものがあるとしたら何かということを考えてものを作るのが進行管理者でも作業者でも求められることなのではないかなと感じた(全員が全員できるようになれという話ではない)。

あとIssue立てる時にテンプレみたいなのも設定できるので、活用していくと良さげ。 Creating an issue template for your repository - User Documentation

CIツールと連携できる強さ

backlogには無い機能として、CIツールとの連携がGithubにはある。Travis CIとかCircle CIとかで自動テストとかデブロイをやってくれるのが凄まじい。これは正直自分のプライベートプロジェクトでは試してなかったので勉強になった。

連携自体は割と簡単で各サービスにサインアップしてプロジェクトを連結させるだけ。あとは設定ファイル(.ymlとか)を弄ってpushして自動で走らすなどしておけば、コミットログの横にチェックマークが出てちゃんと出来てますよーという確認ができる。

gyazo.com

コード品質管理をどうするかということでテストなどを走らせるというのがあり、今までだとこうした連携がなかったので、厳密なものは自社のガイドライン遵守でコード内容が守られているかとかを目測確認したり、そこまででなかったら結構省略することもあったので、PullRequestよろしくレビュー文化みたいなのをやっていく上でも、こうした指標は便利かなと感じた。

作業の進行上、どうしてもWIP的なものであってそれらもチェック走るなどのめんどくささもあるが、一応スキップする機能はあるみたいなので(Circle Ciだと[ci skip]ってコミットメッセージに打てば走らない)内容に合わせて送るようにすれば問題なさそう。

芝が濃くなる嬉しさ

backlogと関係ない完全に私的な内容だけど、芝(=Contributions)が濃くなるのは単純に嬉しい。個人開発をやれている人なら毎日濃くはなるだろうけど、実際問題なかなか芝を濃くしていくのは難しいと思う。通常業務であればbacklogのプロジェクト上で結構頻繁にpush作業をしているので(跨いでるプロジェクトが多いのもあるけど)、自分の芝はもっと濃かったのではないかと思っちゃう。

gyazo.com

もちろんContribution activityとかをしっかり見れば何をしていたかは分かるのだけれど一見のインパクトというものは凄いなとも感じるところ。あとはモチベ維持につながるとかかな。


ようやく本業でもGithubを利用し始めて、個人で使う分では色々と見えなかった部分が見えてきて楽しくなってきたところではある。自分のプライベートリポジトリもいい感じにできそうだなというのも分かってきたので業務と合わせてうまく活用していきたいなーなど。

そんな感じで、こちらからは以上です。

コミットメッセージとコミットの粒度について思ったこと

medium.com

見た。以下思ったことです。


コミットメッセージが結構雑になる問題ってのは、自分が考える中としてコミットの粒度が割とデカい場合になるんじゃないかなと思ってる。

例えば数ページマークアップしたときに、ページごとにコミットを切るよりかは、全ページの作業をコミットさせておく方が分かりやすいし、どこまでの進捗なのかも一見しやすいかなと思う。もちろんページ内で機能が複雑化している場合はその限りではないと思うけど。

なのでコミットのメッセージを分かりやすく書く、ということと同時にコミットの粒度をどれほどのものにするか、という意識と進め方を持たないとこの辺はなりたたないのではないかなーと個人的に感じている。

基本業務の流れとして、バグや機能追加の課題が振られてそれらを対応完了するまでを1コミットとしているけど、LPなどページ単位で対応するときは、場合によっては、1ページ単位でコミットを切ることがある。

あと良くない癖なので直さなきゃなんだけど、その日に対応する修正もまとめて対応して「00/00対応分修正コミット」とかで切って細かく書かなかったりもする。修正範囲の意義を全体的なものとして捉えていると、修正する1機能というよりかはそれに付随するもとしてまとめて対応しないと、という意識になっちゃうのでその辺は進行管理とも付随する問題かなと感じる。

この辺の粒度対策としては、ブランチをいかに細かく切って作業するかにかかってるんじゃないかと思うので手を動かす前にまずブランチ切っとけ、終わったらマージしとけを工程の中に入れておかんと危ないなとは感じた。まあもし単位がデカくなってもやり直しが一応できるのがGitの良いところではあるけど、出来る限りそういう修正はしたくないよね、と。

課題の建て方としてもそうだけど個人としては、もう少し部品化・機能化するイメージで進めてみてもいいかなと感じた。この辺は実験として新規のプロジェクトとか、個人がメインで動いていたプロジェクトにもっかいアサインしたら試してみようかなと思ってる。誰かとやるんであればその時のルールには従います。

余談

昔、コミットの内容なんか見なくてもファイルの内容みればどうなったか分かるだろみたいな言説を聞いて、当時はまあそうだよなと思ったけど、結局属人性を加速させかねない危険な発言だったと徐々に分かってきて、1回限りではない・他人の手にも渡るリポジトリ内では、出来る限りは詳細的に書くように努めたいと思ってる。

こちらからは以上です。

PostCSSの雑感

f:id:cardboarder:20170806221911j:plain

業務で実験的に使ってみたんですが、

まだこの気持ちが強い。とりあえず1プロジェクト終えた後にちゃんとした感想やります。

ただこういうのがプラグインであるのは感動した。

github.com

以上雑日記でした。こちらからは以上です。プラグインの翻訳記事とかつくれば価値出ますかね?