やまろぐはてな

勉強会レポートとか技術メモとか戯言とか

#技術書典4

techbookfest.org

行ってきたよ。

買った本リスト(サークル配置昇順)

  • マンガでわかるWebデザイン+Git
    • マンガでわかるDocker
  • SOLARSOLFA
  • nayucolony
    • こまるUIよくしてみた本
  • CANDY CHUPS Lab.
    • SVGで作ろうローディングアニメーション
  • TechBooster
  • 吉川雅彦
    • IE11以上対応できもちよく書くCSS
  • 犬テトラ+
    • イヌでもわかるウェブフォント
    • イヌでもわかるWebComponents
  • Nikkei Engineer Team
    • 日経電子の本
  • ころころぶっくす
    • "Auth0"でつくる!認証付きSPA
  • Webサービス作り隊
    • マッチングサービスを開発したら大失敗したのでその理由を解説してみた
  • カウプラン機関極東支部
    • jQueryだって複雑なアプリ作れるもん!
  • るてんのお部屋
    • JavaScriptで 実行時エラーを起こす 100+の技法
  • 愛宕文庫
  • ukyoweb
    • オレオレ仮想DOM作りたいだけだった
  • 底なし沼の魔女
    • Libraries of React
    • Get ready for Next.js
  • ねこの手@福岡
    • 現場で使えるVue.js tips集
    • 知らないと損するCSS
  • 帝都研究所
    • Nuxt tech book
  • 御苑×Lab
    • CSSをもう一段階レベルアップさせる本
  • 東京ラビットハウス
    • 最新JavaScript開発~ES2017対応モダンプログラミング
    • JavaScriptで覚える暗号通貨入門#1 Bitcoin完全に理解した 前編
  • YATTEIKI Project
    • 今日からはじめる技術Podcast 完全入門

基本フロントエンドまわりでした。あとyatteiki

追記(20180423)

以下もダウンロードにて購入

  • 好きなコマンドは dig です
    • DNSをはじめよう
  • KUGIBAKO
    • 初めてのシングルページアプリケーション Vue.js と Firebase で作るミニ Web サービス

所感

  • 技術書典はじめての参加だったので開始30分前につけば御の字かなと思ってたら既に500人並んでる状況だった
    • 自分は整理券番号671番目だった

  • 入り口寄りにあったフロントエンド系の「お〜か」島らへんが密集していたというかたぶん配置失敗してたんじゃないかと思うくらい混雑すごかった
    • 逆に奥側の方になるにつれて人の行き来もそこまで難しくはない感じだった。次回は今回の件から配置配慮してほしい
  • 硬貨両替しておいたが、最初入れるか心配だったので使えないのではと思ったが、無事活用できた
    • 札で払うところを500円玉で用意したら喜んでもらえた(計算がアレだったかもだけど)
  • yatteiki.fmでも言及していた気がするけど中の人が見られるという点ではこうした即売会の利点?だよなと感じる。
  • 「技術」書典ともあり、ダウンロード販売しているところもあったり、かんたん後払いシステム もあってやはり先進的な即売会だなぁと感じるなど
  • 技術書ってあくまでも「標準」をめざしたものでかつ高価なものだけど、こうした同人誌としてニッチな内容もとりあげたり自分で掘り下げてみた内容を、(通常と比べて)安価で簡易的に購入できるという場としてはかなりレアなのではないかと思う。

そんな感じでした。もろもろ買い終わってUDXで海鮮丼食ってから家に帰りました。職場が秋葉原に徒歩で行けるレベルなのであとでCOMIC ZINに行ってみます。

こちらからは以上です。

「すくすく!子育てエンジニア Meetup #2」レポート #子育てエンジニア

f:id:cardboarder:20180121213147p:plain

childcare.connpass.com

前回のMeetupから早3ヶ月、ついに第2回目が開催されましたので毎度勝手ながらのレポ。概要などは前回記事を参照ください。

yamanoku.hatenablog.com

tebasaki「育児 × 在宅勤務のTip」

speakerdeck.com

前回 → 育児タスクのカンバン管理 離乳食編 // Speaker Deck

在宅制度、弊社でも制度としてあって子持ちの人にも便利なのですが、本当に育児に有用な手立てなのか?というのを改めて見直すきっかけをくれたような気がしました。

「家に入ればどうにかなる」という曖昧な判断だと危なく、ちゃんと育休を取る・仕事部屋との隔離・作業時間(コアタイム)をしっかり確保する、という計画建てが大事そうです。一度だけ在宅時に娘と二人っきりになる日があって、自分自身も「なんとかなるやろ」の精神でいたのですがなんともなりませんでした(娘大号泣で仕事どころじゃなかった)。

Googleカレンダーでの仕事のものとプライベートのものを連携というのはなるほどでした。会社でのおおよそのスケジューリングを可視化しておくとパートナーにもその様子が分かる・それぞれの予定のバッティングを回避するように考えるきっかけになりそうだと思いました。

あと育児と同じく家族看護も同様に危険性があるので、在宅作業ではなく休むときはしっかり休むようにしないととも感じました。

tamadon「子育てエンジニアを支える技術」

speakerdeck.com

前回 → 自作育児サポートアプリのその後 // Speaker Deck

エンジニア=非同期処理。自動化というイメージのもと、自動化できるものがあればそれに頼っていきましょう、楽していきましょうという紹介。

家電系は前回のMeetupで紹介されていたので割愛ですが、アプリ関連でも色々とあるのだなぁと思いました。写真関連は特に、スマートフォンなどをもっていない親世代でも共有できるものを使っていくのは良さそうだなと思いました。あとAmazon Prime Photosは完全に知りませんでした…あとで見る案件です。

ランドロイド、間違いなく値下げ化を望んでいる人は子持ち家庭以外でもいるだろうなと思いました。高すぎる(当たり前ですが)。

参考リンク

tknzk「子育てをはじめて2.5年の振り返り ~ テクノロジーと創意工夫で家庭と子育てをハックしたい ~」

speakerdeck.com

GoogleHomeの複数連携

以下Cloud FunctionsをWebhookに指定

'use strict';

var request = require('request');
var config = require('config');
var iftttKey = config.IFTTT.key;
var requestToken = config.IFTTT.request_token;

exports.callIFTTTWebhook = (req, res) => {
  if(req.body.secret != requestToken) return;

  var triggers = req.body.triggers;

  for( var i in triggers ) {
    var url = 'https://maker.ifttt.com/trigger/' + triggers[i] + '/with/key/' + iftttKey;
    var options = {
      url: url,
      method: 'POST',
      headers: {
        'Content-Type' : 'application/json'
      }
    };
    request(options, callback);
  }

  function callback(error, response, body) {
    if (error == true) {
      console.log(body);
    }
  }

  // send status
  res.status(200).send('ok');
};

個人的には映像コンテンツノンストップという仕組みをとっているというのが驚きでした…自分の娘もYoutubeに齧りつきになっている事が多く、それだったら浴室にはタブレットを、寝室にはプロジェクターを…という徹底ぶりに恐れ入りました(自分は怖くてできない…)。

エルサゲートも問題視されているので、親と一緒にコンテンツを吟味して見るべきものを考えるきっかけにはなれるのかなぁとも思いました。Super Simple Songsのような楽しみながら学べるコンテンツもあることなので、探してみてそれを子育てエンジニア間でも共有できればいいのかとも感じました。

それとSNSで実名が飛び交うこの昨今、娘さんにソーシャルネーム(?!)をつけてSNSに投稿できるようにしたというのは面白かったです。ウチもなんか付けるか。

参考リンク

kohei_tabata「動線改善とステータス可視化で家庭内のストレスを軽減した話」

speakerdeck.com

前回 → 家庭をプロジェクトとして運営した話 // Speaker Deck

個人的ガチ勢のお方。今回は家事のステータスの可視化・動線の改善についてをどう考えるかがテーマでした。

家事のステータスというと夫婦間でDoneなのかDoingなのかが変わってくるかもしれません。共通認識とするのと、いまどこまで進んでいるのかを可視化できるようにすれば各自でのストレスは軽減(=コントロール)できるのではないか?とのことでした。逐一自分たちの頭で考えなければならないのも形にすればいいよなーと感じます。

動線を変える点でも、ただやみくもに新しいものを導入するのではなく、まずは既存のものを使ってみて、そこからどう形にするかを考えるというのも課題解決の。あとはここの部分の仕様を厳密にとらえず、「ひとまずこういう形はどうか」と7割程度のものでレビュー段階にもっていく、家庭でのプルリクエストを実行してみてはどうかとのことでした。

3Dプリンタ、家庭で導入されているものだと遊び用に使われている感じの印象でしたが、家事を助けるための小物づくりとしても有用だということに気付かされました。ただ導入するには、値段的な部分で、検討が必要な場合がありそうなので、まずは3Dプリンタのある店で出力してもらってモノにしてみるのも手のようです。

参考リンク

Hikoharu06「保活問題についての取り組み紹介」

kidsly.jp

リクルートマーケティングパートナーズの保育園と保護者をつなぐサービス「kidsly」の中の人による保活問題への取り組み事例と現状どういう実情があるかの発表でした。

保活のストレス

保活は子どもをこれから産むお母さんにとてつもないストレスがかかっている。何故かというと、保育園自体の数が少ないことや入るに辺りどこまで点数を満たしているかの検討、見学に行ったり区役所・市役所に行ったり、厳しかった場合お金をかけてまで認可外にするのか、育休が終わるまでになんとかなるのか…と複合的な要因でこれからの出産に大変な不可になることが多い。

ちなみに都内で現在待機児童が多いのは目黒区。

そもそもの保活情報源について

保活を行うにあたり、点数計算はもとより、どこにどういう保育園があるのか・人数はどれくらいまでか・認可か認可外か、という一括で管理しているマスタというものは現状ない(近いものはあるがあくまでも人力)。あとは各自治体での信用できる情報もCSVやPDFデータなど編集しづらい日本らしいデータでしか設置していない問題もある。

また、ママ友などでのコミュニティ形成はあるにしても保育園との連絡や情報の共有は電話などのすぐ確認できるかわからないものだったり、そうした部分も地味にストレスになりうる。

kidslyがこれからやろうとしている保活問題へのアプローチ

kidslyがそうした問題を解消するために、以下のアプローチを掲げている。

  • 保活ストレスからの開放
  • 日本中の保育園情報をあつめる
  • 保活をもっとオープンに

保護者間でのコミュニケーションを充実させたり、園からの情報を共有しやすくしたり、何よりアナログでやっていたやり取りをデジタルに落とし込むといった方法をとろうとしている。

保活問題へのこうしたアプローチがリクルートじゃないとできないと思うのは、収益化の問題に対応できる(潤沢なリソース)、ママユーザー基盤が充実しているから。この部分は、大きな社会問題として切り込むためにも、たしかにそうだとしか言えません。

kidslyの導入園は今年3月の時点で1000に達成したとのことで、この輪がどんどん大きなものに変わっていけばいいなと思います。

参考リンク

shikichee「- 技術的夫妻プレゼンツ- 家庭内タスクをスクラム的に考える方法」

speakerdeck.com

夫婦揃って最近noteの記事でバズりを見せていた旦那のshikicheeさんによる発表。夫婦で共働きの際に問題となる「収入の管理」と「家事のステータス」のそれぞれを認定スクラムマスターがスクラムで解決。

スクラムの3つの重要要素は以下とおり。これらをルーティンさせていく。

  • 透明性(次の行動へ活かすため必要な情報を集約させる)
  • 検証(現状とゴールまでの差分を確認)
  • 適応 (検証での差分をいかに減らすか)

お金の管理や家事のステータス化ではお互いの状態があまり透明化されていないのがストレスとなることがある。そのためにもまずどういうことになっているのか、共通にすべきものはなにかを考えてみる。

お金であれば家庭内で使うものは共有口座で管理し、残りはお互いの口座で管理。家事であればどういう手順を組むのか、そして今どれだけやってるかどこまで終わったかをカンバンサービス(Trelloなど)で可視化していく。こうした目に見えるものにしていくことでストレスをなくし、お互いの幸福度につなげていく。

あとはこうした解決方法でいく!としてもパートナーがそれに乗り気になるか、そもそも興味をしめしてくれるかというのもある。そうした場合ひとまず1人で進め、相手が触れやすい状態にしていく、今後もやってくれるよう声がけをするなど、ただやるだけではなく巻き込んでやることを意識した取り組みが必要になる。

いずれにせよこうした解決をするためには、まず夫婦間での意識の共通化と、お互いを理解しておくということが大切とのことでした。

便利な家電を買う場合の以下式は非常に参考になるなと思いました(購入金額より勝るならGOサイン)。

購入金額 < 耐用年数 * 1年の使用回数 * 1回の削減時間 * 自分の時給

参考リンク

感想

今回も実りある内容ばかりでした。前回はアプリエンジニアの視点でのフォローという印象があったのですが、今回はエンジニア思考の視点においてどう家庭補佐するか、という感じだったので「何かモノをつくる」ということだけに徹しなくても、また別のエンジニアリング手法(スクラムなど)でフォローは出来るのだなと感じました。

更に根強い保活問題にも切り込んだ発表もあったので、ここから解決の方向へ広がる共有があれば、技術的解決をもって大きな課題に一矢報いることはできるのではないのかなぁと更なる可能性も感じました。

このブログをまとめる間に思っていたこととして、OSSプロジェクトみたいなのを設立して、子育てプロダクトをみんなで育てていく、という動きもあればいいのかなぁと思います。やっぱり都内での開催になるので、少しでも場所を問わずに多くの方が参入できるものを徐々に広げていくと、もしかしたら国内のみならず諸外国での「子育てエンジニア」の知見もあるまるのではなかろうか…と軽く妄想です。

次回はそろそろ登壇側として何か提供できるものがないかなぁなどと考えたりしています(できるとは言ってない)。些細な内容でも、受けた影響により動いてみた内容など、他の人の背中を押すきっかけになればいいのかなぁと。

こちらからは以上になります。


興味が有る方は以下よりJoinをばどうぞ。

子育てエンジニアSlack Join

https://join.slack.com/t/childcare-engineer/shared_invite/enQtMjkxMDE0OTMwMDE3LTNiZmM0NmViZmZkMzMzNjlkM2YzNzI2MmU4ZmRmNGM1NzRiOTIwZjExMmFiZGFiZTVlMjBkNzNiZWQyNWQ2NDI

子育てエンジニアScrapbox Join

https://scrapbox.io/projects/childcare-engineer/invitations/f61f79a4c64999afc3deb04887af0530

「すくすく!子育てエンジニア Meetup #1」レポート #子育てエンジニア

f:id:cardboarder:20180121213147p:plain

実は私は1歳(ver1.10.2)の娘をもつ父親(ver28.2.3)エンジニアです。DeNAさんとこのイベント会場で面白そうなMeetupがあったので参加レポートです。

childcare.connpass.com

続きを読む

CSSとわたし、正義と悪、そしてこれから。

この記事は CSS Advent Calendar 2017 16日目の記事です。

テック的なことを書こうかと思いましたが、これまでの人生を振り返ってきて自分にとってのCSSとは何か、そしてこれからどうやっていくべきかみたいなことを書こうと思います。Qiitaに書くのもあれな内容と判断したのでブログの方にしました。

「はじめて公開された」CSS

自分が、個人の制作物以外で「世の中の人に初めて公開された」CSSはこちらになります。

github.com

なんだかよくわからないものばかりになっております。自分で推測しますが、どこかしらのテンプレートから拝借してそのまま置いてみた感じかなと思います。まぁ当時の独学でアレコレやったド素人が書いたものなのでそんなもんです。

美術系の大学出身*1なのですが、一応サイトを作れる人間だったので当時の卒業制作展のサイトを勝手に担当していました。

卒業年が2008年なのですが当時はiPhoneが出回り始めて、いわゆる「スマートフォン対応」というものを徐々にしていかないといけない時代だったと思います。当時の自分はレスポンシブ対応することまではできなかったなりに、「PCはPCの体験を、SPはSPの体験をすべき」という考えをもとにSPページを用意して .htaccess でユーザーエージェント判定をして振り分けなんぞやってました。

当時の有名美大の卒業サイトと見比べると月とスッポン、いや比喩することすら失礼にあたる可能性があるくらい出来は微妙なのですが、素人なりに真新しいことは無理にやらず、ちゃんと情報にたどり着ける阻害しないようなスタイル、そしてCSSは分けてスタイルも分割するなんていう生意気なことをやっていたんですねぇ。(ただし内容はグダグダな感じです)

CSS2 => CSS3

f:id:cardboarder:20171214231200j:plain

さて、思い出語りから話をガラリと変えてしまいますが、CSS3というものがこの世に出てからどれくらいが経ったのか皆さまはご存知でしょうか。

調べたところどうやら「CSS2.1」が確定された2011年より策定が進んでいる*2とのことで、誕生?から6年ほど経っているようです。

先程紹介させていただきました卒業制作展サイトにもCSS3 Media Queriesを使用したり、box-shadow要素やgradient、border-radiusといった要素を使用しておりました。

これまで自分の中でCSSというものはサイトにある要素を「整える」ものという認識でいて(今もそんな感じかとは思いますが)、キッチリとやるために必要なものだと思っていました。

それがCSS3になって、より多彩な表現の幅を広げてもらえるものになったと思い、当時は画像などで対応せざるを得なかったものをCSSで対応してくれる革新性には驚かされました。

CSSとはこんなにも自由なものなのになったのか!それはとても素晴らしいことだと当時の私は感嘆しておりました。

プリプロセッサ、ポストプロセッサとの出会い

f:id:cardboarder:20171214231345j:plain

手書きでCSSを書くことが当たり前だった私が転職先で「えっ素でCSS書いてるの…マジ…?」と言われるくらいには古いやり方だったようで、双方に驚きがあったようです。

素のCSSを弄る時代はいつの間にか終わっており、代わりにLess、Sass、Stylusといったプリプロセッサ言語で楽にCSSを書ける、管理しやすくすることが出来ることを知ってから、世界はこんなにも広かったのか!というような気がしました。

中でもStylusとの出会いは特に衝撃的でした。何故かというとインデントで階層管理して、あの煩わしかった{}やコロンも省略可能で記述スピードを爆速にしてくれるのには感動しかありませんでした。

出力された後に調整する「ポストプロセッサ」なるautoprefixer、minify、PostCSSといったものにも触れ、ブラウザごとのバージョンに合わせて、またはCSSの機能を拡張してくれるなど、これらもまた私にとっては大変重宝しているものたちでした。

「設計思想」というものがある

f:id:cardboarder:20171214231609j:plain

これまでCSSについてなんとなくで書いてきた私でしたが、仕事をしたり、インターネットを潜っていると「世の中にはCSS設計思想というものがある」ことを徐々に知りました。

有名どころですと、OOCSSSMACSSFLOCSSBEMなどでしょうか。

設計思想とはいわば、CSSをこういう風に切り分け・管理・拡張すると運用や再利用がし易い設計となるのではないかという考え方をもとにそれぞれのアプローチが提案されています。

自分が業務として体験してきたのは、SMACSS、BEM、そしてECSSです。

f:id:cardboarder:20171214225459p:plain

当初はBEMを使った設計を全面的に目指そうと考えていたのですが、ECSSが我々の業務内での設計とfixするのではないかと考え、今はECSSをベースとした設計思想で作成しています。

これまでの経験則として、ファイル数は増えるがもっとも追加や更新のコストを軽減しうるものではないかなと感じています。

CSSは世間で「忌み嫌われている」言語だった

そんなこんなで便利なツールや意味のある設計思想を使ってCSSを書くことが楽しくなってきた筆者にとある避けられない事実を突きつけられました。

それはCSS

  • 「明確な解決法もなく」
  • 「保守しようにも破綻しかねない」
  • 「一番考えるのが煩わしい」

言語ということだったのです。

おいおいそんなこと言うなよ!こんなにも素晴らしく楽しい世界にそんなことなんて…そう思って私が振り返ってこれまでのCSSを見てあることに気づきました。

「同じように生み出されたstyle.cssなのに、よく見ると…ルールや内容が全然違っている…!」

クライアントワークを行う上で、要件や仕様というものが決まっていると、それに準拠するために設定などを見直す必要がでてきます。また、外部の方に制作を依頼するときも少しでも綻びがあるとそこから新たなるルールが発生してこちらがオーバーライドしかけるという事態も起こり得ていたのでした。

加えて運用案件においてもソースコードが誰かしらの手に渡り、制作意図もうまく伝わらぬまま変わり果てたstyle.cssとなって残り続けているものもあり、それをメンテナンスしなければならなくなるということもあったそうな(この段落はフィクションです)。

もちろん下準備した我々がそうした事態を考慮できてなかった問題もあるのですが、それにしてもここまで顔が違くなることはあるのか?多少の設計やプリプロセッサは違えど、何故みんな同じようにできなかったんだ?などかつての思い描いていた何でもできる素晴らしいCSSは一体何処へ…?

もしかしたらCSSを誤解していたかもしれない

そうした失敗への気付きから今一度CSSについてを考え直していました。

こんな書き方をしてしまえば身も蓋もないのですが、よほど長期運用するサイトであったとしても、万能薬として効く設計思想やプリプロセッサ、そしてそれをもとに得られる、再帰性があり可読性も高く更新しやすいCSSを生み出すということは、まず難しいということです。

これはCSS自体が悪いものなのか、と考えることもできるのですが、私自身はそうではなく、むしろそうしたCSSに合わせられないサイト設計、UI設計が良くないのでは? というある種の責任転換みたいな、しかしながらそうしない限り破綻が続くような考えを持つようになりました。

「なんでや!自由度の高いサイトデザインができなくて何がWebや!」という意見もごもっともだと思います。

ですが、結局のところウェブに残るものとは文化資産に近いそれらだと思っており、そういった文化をメンテもできない冗長性しかないもので管理するのはいかがなものか…とも考えられるのです。

なので、極端ではありますが、現状CSSとの付き合い方はこうするしかないのかなと思っています。

  • サイト設計やUI設計といったものをメンテナンスできて要素を更新するにも容易に対応できるものとした上で、正義のCSSを生み出す
  • 新たなクラスをどんどん生み出し、他のセレクタなどに影響を出さないことを前提とした闇鍋のような悪のCSSを生み出す

極端過ぎる。でも結局はどちらかになると思ってます。

ただ、正義のCSSを生み出すために、CSSに対してみんなで優しくしろ、という訳ではないと思っています。

何故かというと、CSSに優しい設計を考える上で、CSS以外もきちんとどう運用すべきか、どう管理すべきか、どう設計すべきかなどが徹底されて初めて成り立つものだと思っているからです。

だから世間で忌み嫌われているCSSは、自由度が高すぎるがゆえに「なんでもしてくれる床上手な処女」のような空想上のものとどこかで錯覚しているのかもしれません。CSSもほかの言語と変わらぬきちんと運用されないと破綻されるものと一緒なのです。

CSSを見直すヒントたち

そんなCSSたちをどうやって見直していけばいいか?という部分においてヒントとなりえそうなものがあるので紹介していきます。

宣言ブロックは慎重に精査する

kojika17.com

kojikaさんのブログでも述べられていたように、CSSにおいてプロパティや値を管理する宣言ブロックについてはあまり意識していなかったようにも思えます。

たしかにどこかで !important を入れてしまうとそれをオーバーライドするために元あった宣言ブロックのルールが破綻してしまいかねないことや、汎用的に使いこなしたいのにwidth指定やテキスト方向などが変更できないものなど、想定していたものと別の形になってしまうことがあります。

こうした事態を避けるためにもデザインの確認やある程度余白を意識した宣言を書くようにしないといけません。割とタグに直接書く悪習はなかなか治らないので、そこで左右されないように大元をも見直すことも大事かと思われます。

stylelintにおける品質維持

f:id:cardboarder:20171215010857p:plain

JavaScriptの構文チェックに使用されるeslintというLintツールがあるのですが、それのCSS版Lintツールに「Stylelint」というものがあります。

CSSを綺麗に整形できているか?統一化された書き方ができているかという面で有用なのですが、他にも「!importantを使っていないか?」「階層を深くしすぎていないか?」「プロパティが重複していないか?」などの宣言ブロック関連のチェックをしてくれるものもあります。

標準のLintルールが割とすぐに使える(エラーも少なめ)なところもあるので、必要な部分を徐々に継ぎ足して、ルールをもった可読性のあるCSSを実現させましょう。

コンポーネント指向におけるパーツごとでの管理

f:id:cardboarder:20171214232901p:plain

正義のCSSを生み出す上で、私の中での1つの解として考えているのがコンポーネント管理です。 レイアウト、ページ、パーツという単位で切り分けそれらを組み合わせる…いわゆるアトミックデザインのそれに当たりますが、とにかく範囲をぶつ切りして影響範囲を減らしていく過程というのは必要なのだと思いました。

そういう意味ではNuxt.jsというプロダクトがまさに適応しうるのでは?と考えております。CSSに関してはstyle scopedが使用できるので、より閉鎖的に他とバッティングすることもなくセレクタの命名問題点も解消できるかもしれません。

github.com

ただ、問題点を解消できる参入しやすいプロダクトだと思うのですが、まだまだ汎用的に使用するには有用な情報が少ないので、「まだ」確実な一手とはなってないかと思います。ですが参考にしうること(ディレクトリ構成など)は多いと思います。

他にもReactをVueライクにするone-loaderというプロダクトもあるみたいです。

github.com

正義のCSSをやっていこう

f:id:cardboarder:20171214233002p:plain

上記3点の他にも解決しうるものは探せば出てくると思うのですが、それをこれからすぐにやり始める・導入するというのもなかなか難しいことのように思えます。何故ならこれからのCSSを失敗しないようにしても、これまでのものを無かったこと・解決したことにはならないからです。贖罪とはならないのです。

私自身も数多くの「悪のCSS」を生み出し続けてきました。生み出してきたものを無かったことにすることはできませんが、彼らをもう一度、正しい方へと導いていくことはできるかもしれません。そのためにも何故こういう状態になっているのか・どうすればまとめられるのかを見直していくことが必要になります。

ですが、かつては皆が信じてやまなかった「正義のCSS」として作られていたはずのものであるならば、実現しようとしていた正義の片鱗のようなものがどこかにあるはずです。そこを頼りにかつての正義(もしくは新たな希望)を取り戻しに行くことはできるかもしれません。*3

最後にこの言葉をもって終わりとしたいと思います。ご覧いただきありがとうございました。

悪に報いるには正義をもってし、善に報いるには善をもってせよ。

孔子

*1:今は学部ごと移動して事実上の消滅

*2:https://allabout.co.jp/gm/gc/376450/

*3:もしかしたら最初から破綻を前提とした「純粋悪なCSS」も存在すると思いますが、その場合は闇に葬り去るか完全にリセットした方がいいかもしれません

「さくらインターネットのエンジニアは 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