やまろぐはてな

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

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

f:id:cardboarder:20180121213147p:plain

childcare.connpass.com

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

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なのかが変わってくるかもしれません。共通認識とするのと、いまどこまで進んでいるのかを可視化できるようにすれば各自でのストレスは軽減（＝コントロール）できるのではないか？とのことでした。逐一自分たちの頭で考えなければならないのも形にすればいいよなーと感じます。

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

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

参考リンク

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

kidsly.jp

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

保活のストレス

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

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

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

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

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

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

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

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

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

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

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

参考リンク

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

speakerdeck.com

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

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

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

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

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

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

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

便利な家電を買う場合の以下式は非常に参考になるなと思いました（購入金額より勝るなら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

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

this や props の型推論ができて、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

初心者にGit教える時に必要最低限のCUIコマンド

git 初心者

f:id:cardboarder:20170116221632p:plain

前提条件

ガチ初心者でgitの操作をCUIで学ぶため、基本１人でmasterで作業するという「いやお前それGit管理じゃないだろそれ」という前提でやってもらます。いいんだよ細かいのはこれから学んでいけば。

作業前にリポジトリとかはどこかで作って置いたほうがよい（Github、Bitbucket、backlogなど）。

必要なコマンド群

リポジトリのクローン ... gitを使う設定

git clone https://xxxxxxxx/xxxx.git

※この時もしかしたらログインIDやパスワード聞かれるかもだが、気にせず入力してください

作業ファイル全追加 ... 作業したファイルを保存

git add -A

コミットメッセージ ... 何の作業をしたかの記録

git commit -m "commit message"

プッシュ ... サーバーにアップする

git push

プル ... 人が作業した分を同期・ダウンロード

git pull

右のはあくまでもそうした意味ではなく、イメージ。だいたいこれで足りる。自分は足りた。

cloneした後に「作業 → add → commit → push」を基本ローテーションとして作業。

必要に応じて他の初心者を入れて同様に作業させて、pullを理解してもらう。コンフリクト起こしたら、その時は都度修正、コミットなどしてくれ。

基本の骨組みはこのイメージでいいのではないか

実際Gitは様々なコマンドがあったりフローが存在して、いわゆる「ちゃんと理解できたらちゃんと使える」代物とも言われてるので、使いこなすにはある程度知識や経験が伴う。

とはいえ自分がやってきた中では基本このイメージさえできていれば、後はそれに付随する肉付きをしていけばいいんじゃないかと思っている。

たとえば作業でpushまでしたけど実は違ったものが最新になっていたのでそれを直すというのがあった際に、上記コマンドであれば作業後に再びadd、commit、pushなどをする一連の流れがあるわけだが、そのままだと煩雑なコミットログになりかねない（別に慣れる間であれば気にしなくて良いのだが）

そのためにgit revertだったりresetだったりcheckoutというコマンドが調べて出てくるのだが、そうした時に学んでいけばいいんじゃないかとは思う。

それなりに親切なGit

あとGitは丁寧なので、たとえば新しくブランチを切って作業して何も考えずadd、commitしてpushすると「リモートにそんな追従ブランチねーよ」と教えてくれて以下のコマンドを提示してくれます。

git push --set-upstream origin branch

アメリカ語だけど頑張って訳せばそれなりにちゃんと教えてくれてるんだというのがわかる。なので極端に怖がらなくてよいのだ。

極端な言い方をさせてもらえば、やり方次第でなんとかなるのがGitである。

Git教育について知見が欲しい

ウチではこうやってるよ的なのを募集しています。

こちらからは以上です。