「改訂新版 Vue.jsとFirebaseで作るミニWebサービス」を読んで

書籍

改訂新版 Vue.jsとFirebaseで作るミニWebサービス (技術書典シリーズ(NextPublishing))

改訂新版 Vue.jsとFirebaseで作るミニWebサービス (技術書典シリーズ(NextPublishing))

この本を選んだ理由

  • 以前「WebAPIアプリケーション「超」入門 FirebaseとAPIによるWeb会議システム制作」を読み(読書記録はこちら)、Firebaseについて興味を持ったから。

印象に残った点

(以前に読んだ本よりも)Firebaseについて詳しく書かれている

  • Firebaseはスケーラブルだが大量のユーザやトラヒックを扱うとなると運用にかかる費用は自前でバックエンド開発したほうがコストが安くなる傾向があるとのこと
    • どこのラインが境界になるのか?は別途調べないと分からないにしてもありがたい情報。
  • 本を読みながら実装すればGoogleアカウントでのログイン&ログアウトも簡単に実装できる。やりおるFirebase。
  • Firebase DatabaseはJSONで設定を記述する。認証だけではなくValidateやIndexの設定も出来る。(参照)
    • 認証設定はカスケード式なので数珠つなぎで設定が引き継がれるが、Validateはカスケード式ではないので個別に書く必要があるらしい。
      • Firestore学びたいのぉ。
  • value イベントを使用して変更をリッスンするにはon()またはonce()を使う。(参照)
    • on()であれば常に、once()であれば一回だけトリガーされる。
    • Valueの対象は指定したDBのパスの子要素が変更されても対象になるとのことで、rootを指定するとめちゃ呼ばれてえらいことになるらしい。
  • ただ、Firebase Functionはこの本に記載がないのが心残り。

コラムの「ちょい足しポイント」や「用語説明」があり、私のような初学者にとってありがたい

  • 「次にこの内容を学びたい!」「そのワード気になってたんで補足あって助かる~」ということが多く、個人的には凄く良い。
  • CircleCIでFirebaseのdeployができると書いてあり、脱線してCircleCIを触るきっかけとなってとてもありがたかった。
    • 以下記事を参考にし、githubにPushしたらCircleCI経由でFirebaseに自動デプロイできて感動した。
      • CircleCIの基本はこちらを参考にした。
      • Firebase連携はこちらを参考にした。

フロントエンド開発(JavaScript/Vue.js/CSS等)についても色々と学ぶことができる

  • 少し齧ったことがあったので、得られることは多かった。
    • 完全に初心者だと少しとっつき辛いかもしれないと思った。
  • 下記については知らなかったので良い勉強になった。
    • vue-cliのWebpack-simpleテンプレート使うとwebpack-dev-serverが入るのでローカルサーバ立ち上げれる。
    • webpackのSourceMapとはなんぞや?ということがわかった。
    • marked入れると簡単にMarkdownエディタ作れる。
    • 標準のCSSはmargin等が入っていて意図通りのデザインにならないことの原因になるため、一度リセットすることがあるとのこと。知らなかった。
    • githubMarkdown表示用CSSあるんだ。へぇー。
    • ロゴフォントの試し書きサイトがあるんだ。へぇー。
    • Webサイトの利用規約について書き方が書かれているサイトがあるのか。そのサイトを参考にしつつ類似サービスの規約も見て随時追記すると良いとのこと。規約について触れることもなかったので勉強になるなぁ。

今後

  • Vue.jsもう一回勉強したいなぁ。
  • (Firebase Function以外でも良いので)FaaSについて学びたいなぁ。

余談

  • ブログへのアクセス情報をもっと細かく知りたいと思い、こちらを参考にGoogleAnalyticsを導入してみた。
    • もっと早くから導入しておけばよかったと後悔している。

「誰でもつかえる!ウェブフォント実践マニュアル」を読んで

書籍

誰でもつかえる! ウェブフォント実践マニュアル (技術書典シリーズ(NextPublishing))

誰でもつかえる! ウェブフォント実践マニュアル (技術書典シリーズ(NextPublishing))

この本を選んだ理由

  • ウェブフォントについて全く知らないので、知識の幅を広げたいと思ったから。

印象に残った点

フォントやウェブフォントについての基礎が書かれている

  • フォントはグリフの集合体である
    • グリフは文字や記号を表現するベクター図形のこと。
    • フォントファイルのサイズはグリフの数によってきまるため、日本語フォントはグリフの数が多く、パスも複雑な文字が多いためサイズが大きくなる。
  • ウェブフォントにも形式がある
    • EOT、TTF、WOFF、WOFF2の4種類がある。
    • IE11以降のモダンブラウザであればWOFF2のみで良いが、古いIEもWOFF形式も用意する必要がある。

ウェブフォントを自前で用意することも可能

  • ネットからダウンロードして、サブセット化してサイズを小さくすると良い。
    • 商用利用可でもウェブフォントは駄目や例もあるので注意が必要。
    • サブセット化は「JISX0208 第一水準漢字+記号+基本ラテン文字+カタカナ+ひらがな」が一般的。
    • サブセット化することで約15MBが約700KBになる。
    • サブセット化はフリーソフトが存在する。
  • 最適化したフォントをサーバへupし、CSSの@font-faceで定義したフォントを利用する。
    • 複数定義すると上から順に呼ばれるので優先したいほうを上に書くこと。
  • 勿論ウェブフォント配信(Google Fonts)サービスもある。

フォントの遅延読み込みはレンダリング遅延を引き起こす

  • HTML/CSS/JavaScriptを受信し、ピクセルとしてレンダリングするまでの中間段階で行われている一連の処理の流れをクリティカルレンダリングパスという。
  • コンテンツの初回描画とフォントのダウンロードが被ることが原因。
  • ブラウザ内部のフォントの扱いは3つのチェックポイントがあるが、ブラウザ間で挙動が異なる
    • block period、swap period、failure periodの3つのチェックポイント
      • こちらに3つのチェックポイントを表現した図があるので参考に。
    • block period→swap period間の切り替わるタイミング、フォールバックの有無がブラウザで異なる
      • safari厳しい。ダウンロードまで待ち続けるんか。。。

ウェブフォントではFOUT、FOUTという問題がある

  • FOUT(Flash of Unstyled Text)は代替えフォントが表示されてしまった後に指定フォントへ表示が切り替わることでおきる瞬間のチラツキのこと。
  • FOIT(Flash of Invisible Text)はsafariではダウンロードを待ち続けるのでダウンロード完了までテキストが表示されなくなる問題のこと。
    • CSSのfont-displayプロパティでFOUTやFOITのタイミングを制御できる。
    • JavaScriptのFont Loading API/Web Font Loaderでも制御できる。

ウェブフォントの扱いには注意が必要

  • フォントの再配布(フォントをウェブフォントとして利用)、フォントの改変(サブセット化)にあたる可能性がある
  • SIL Open Font License、Apache License 2.0、M+ FONT LICENSEであればウェブフォントとして利用できる。

オススメの日本語フリーフォントが書いてある

  • これはWeb素人にはありがたい項目。

今後

  • ETag、Cache-Controlなど全然知らないワードが多かった。WEBに関するより基礎的な技術を勉強してみようと思う。

「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」を読んで

書籍

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

この本を選んだ理由

  • 自分のチームでは月イチで振り返り(KPT)を行っているがマンネリを感じており、より効果的な振り返りができるようになりたいから。

所感

レトロスペクティブの構成は5つのアクティビティがある

  • ①場を設定する、②データを収集する、③アイデアを出す、④何をすべきかを決定する、⑤レトロスペクティブを終了する
  • この構成は1時間でも3日間でも可能
    • ①や⑤をやっていないのでまずは自分のチームからやっていきたい。

レトロスペクティブの目標を後押しするアクティビティを選択する

  • 教育のあり方を評価するARCSは選択する上で有効な基準
    • Attention(注目)、Relevance(関連)、Confident(自信)、Satisfaction(満足)
  • 時間が経ってアクティビティに興味を失ったり飽きたりしたら新しいアクティビティを見つけ興味を持たせることが必要。
    • わかるー。既に飽き気味でこの本を読んでる。引き出し増やしチームに提案してみる。

「あなたが言葉」ではなく「わたしが言葉」を使うとよい

  • 「あなたが言葉」だと責任の問い詰め、一方的な決めつけになるので注意しないといけない。「わたしが言葉」であれば気づきや経験に重点が置かれ決めつけをしたりしない。
    • 2人チームだとわたし言葉でも裏を返せばあなた言葉に取られる可能性が高いよなぁ。気をつけて発言しないとアカンなぁ。

場を設定するアクティビティにESVPというものがある。

  • ESVPとはExplorer(探検家)、Shopper(買物客)、Vacationer(行楽客)、Prisoner(囚人)の頭文字を取ったもの。
    • 振り返りを始める前に囚人がいることがわかること自体がスゴく有用だと感じた。いたらいたで自分は戸惑いそうだが。。。
    • スゴく面白そうでやってみたい。ただ、2人だと誰がどの属性か分かっちゃうのはアカン。規模が大きくなったらやってみたい。

データ収集時に色分けやカラードットを使う

  • 付箋の色分けはカラードットを使って感情/イベント/職務/テーマを分けると分かりやすい。
    • ただ見た目にこだわり過ぎず重要なテーマに対して色分けすべき。

無口な人が多いチームなどでも「555」を使うとチーム全体からデータ収集ができる

  • 誰もが振り返りで話せる訳ではないので、無口なメンバーがいる場合やしゃべりすぎるメンバーがいる場合でも有意義な方法だと感じた。
  • 引き出しとして持っておきたい。

達成したい目標をサポートする要因と抑制する要因を認識し、効果的なアクションを決める方法として「フォースフィールドアナリシス」がある

  • チームだけでは解決できない目標に対してどういうアクションを取るべきか2つの要因(サポート/抑制)から分析する手法
    • 達成したいことがあってもチームだけでは解決できないから辞めておこう。。。と考えることさえ避けることがある。費用対効果をしっかりと見極めるためにもこの方法は有用だと思う。

課題/アイデア/提案の優先順位をつけるために「ドットによる優先付け」をする

  • 1人複数のドットを持ち対象のアイテム(課題/アイデア/提案)に投票する。1人に10ドット持たせたり、アイテムの1/2-1/3持たせたりと投票の仕方は様々。
  • 質問の仕方としてインパクトや重要度を意識しなくても良い。チームで実現できることが重要で取り組みたいことをフォーカスしても良い。
    • これは良い。ペイオフマトリクス使っていたが、軽い案件が落ちるし、重たい案件への挑戦が増えて疲弊してしまう。次の振り返りでは何を取り組みたいか?という問でドット投票してみる。

SMARTな性質をもつ目標であれば達成できる可能性が高い

  • Specific(明確な)、Measurable(計測可能な)、Attainable(達成可能な)、Relevant(適切な)、Timely(タイムリーな)の頭文字をとってSMART。
    • 次のアクションを決める際でも同じだなぁ。また、Timelyが入ってることが面白い。鮮度ということだろう。

イテレーション毎のレトロスペクティブではアクティビティを変えると良い

  • 毎度おなじみのアクティビティだと飽きるので、「短い話題」のバリエーションを使って議論の観点を変更すると良い
    • KPT、喜/怒/哀、上手くいったこと/次回はやり方を変えたいことなど。
      • わかるー!!飽きが来てる。飽きない工夫は必要だという後押しはありがたい。

レトロスペクティブを終了するアクティビティでは気持ちを上げることが大事

  • プラス/デルタ、感謝など振り返りで疲れているので、ポジティブなフィードバックや感謝の気持ちを伝えることが重要
    • 今のチームは出来ていると思う。専用のアクティビティまで用意する必要はないと思うが、引き続き意識してポジティブフィードバックをしていきたい。

規模を大きくしたレトロスペクティブもあるがチームレベルとは進め方が異なる

  • リリースやプロジェクトレベルはチームレトロスペクティブと異なる視点での改善ができる為有用
  • ただ、イテレーション単位でレトロスペクティブをしているチームであれば慣れているが、リリースやプロジェクトレベルだとレトロスペクティブに不慣れな人が多い
    • 参加者のバックグラウンドや人数の多さなどチーム単位に比べ気をつけることが多いようだ。上司に読ませたい。

今後

  • まずは自分のチームにて飽きが来ないようにアクティビティを少し変えてみる。
  • カラードットや付箋紙の色分けなど、見た目だけでグルーピングすることで議論にフォーカスを与えられるので、使っていきたい。
  • チームだけではなく、更に上位の組織にて振り返りが出来ないか上司に提案する。
  • 二人は匿名性がないので、使えない/使いづらいアクティビティが多いと感じた。
    • つまり、匿名性が高くないと効果的な振り返りがし辛いというところだろう。心理的安全性を作る方法を2人の場合でも考えていきたい。

「なぜ、あなたの話はつまらないのか?」を読んで

書籍

なぜ、あなたの話はつまらないのか?

なぜ、あなたの話はつまらないのか?

この本を選んだ理由

  • 雑談力が乏しいと感じており、面白い話が出来るようになりたいと感じているから。

所感

つまらない話のパターンは4つある

  • ①内輪受け話、②自己中心的な話、③ダラダラ時系列話、④結論ポロリ話の4パターン。
    • ①や②は話がち。特に①は話し相手のコンテキストが揃ってないといけないので、話題を考えるときは意識していきたい。

おもしろい話をするには正しい順序立てがある

  • ①おもしろく伝えるために必要な要素をチョイスする、②チョイスした要素をよりおもしろく伝えるために順序立てが必要。
  • ②はざっくりいうと「フリ⇒オチ」があるかないかということ。
    • 話のプロ(お笑い芸人や噺家など)はこのチョイスと順序が上手なのだろう。

面白い話の重要なポイント=共感であり、聞き手が共感して初めて初めて面白い話となる

  • 1対1であればまだしも、不特定多数に対して共感できるポイントを見つけるのは難しいの。
    • そういう時のヒントとして「共感のピラミッド」があるとのこと。
共感のピラミッドとは、三角形の下から上に「家族」「学校」「食・住」「恋愛・仕事」「芸能」と並べた図。
下にいくほど共感を得やすく、初対面の人には下から上にスライドさせていき相手の関心を探ることもできる。

「フリ⇒オチ」にもテクニックがある

  • フリからオチまでが長い場合は「アバン」を使うとよい。
    • 「アバン」とはフランス語と英語の造語「アバンタイトル」を略したもので、番組が始まる直前に流れる見どころVTRのこと。
    • 関心を引くことができるとのことなので、これは良いなぁ。
  • エスチョン法を使うと聞き手が今まで他人事だった内容が自分事になり、注意を引くことができる。
    • ほんまでっかTVでいうタイトルの所。なるほど確かに注意を引く。スピーチする際のテクニックとして参考になる。

毒舌は「相手に愛を持つ」「名指ししない」ことが大事

  • 毒舌で有名な人を例に挙げて説明していたが、ポジティブ+ネガティブであだ名を付けたり、直接名指ししないというのは言われて気づいた。
    • 毒を吐いて笑いを取るには相手への尊敬や愛情がないといけない。当たり前のことをちゃんと出来ていないと毒舌はできないということを改めて認識した。

今後

  • 話し方のテクニックは学ぶ所はあったが、結局のところ話を受ける側のことをどれだけ思いやったり気遣いができたりできるのか?が面白い話の本質だと感じた。
  • 今後は話を受ける側が今の話を聞いて何を感じるか?をより意識して話をしていきたい。

その他

  • Kindleのエクスポート機能はブログをまとめるときに便利。
    • ハイライトした箇所が引っこ抜ける。Kindle本で買いたくなってしまう。

「プログラマの数学第2版」を読んで

書籍

プログラマの数学第2版

プログラマの数学第2版

この本を選んだ理由

  • プログラミングに役立つ「数学的な考え方」を身につけよう。というイントロに興味を持ったから。
  • 通勤中に読む上で写経をする必要がなく、リラックスして読める本を探していたから。

所感

「初歩的な」プログラミングに役立つ数学的な考え方が身につく

  • If文、For文、While文など初めてプログラムを学ぼうとする人が事前に読むと理解がスムーズになる本だと思う。
    • 高専で初めてプログラムを学んだ時2年くらいは暗闇を彷徨っていたが、その時この本を渡されていたら少しは早く暗闇から脱出できていたと思う。
  • ただし、基礎が分かっていても言語化する難しさを感じている人は一読する価値はあると思った。
    • プログラムするならこう書くべき!と思っていことが、とても上手に言語化されている。

日常生活のゼロを意識する

  • 本には「薬を3日飲んで1日休むを繰り返すには飲む日か飲まない日かを判断しないといけない。ただ、効果のない薬を用意してルールを毎日飲むというように単純化できる。」という例題があった。
    • この発想はプログラムだけではなく、複雑になりすぎているプロセスについて単純化する際の切り口として日常業務にも使えるなぁ。

-周期性や偶奇性(パリティ)を見抜く

  • 手に負えない数でも周期性を見抜けば取り扱うことができるし、偶奇性を使うことで試行錯誤の回数を減らせる。
    • 物事を詳しく調べる際は正確に把握しようとするが、的確な分類をするほうが役に立つという良い例。
    • 的確な分類。ここが仕事においても肝だと思う。

雑談ネタで使えそうな内容が多い

  • ローマ数字は位取り記数法ではない
    • 今まで気にもしてなかったけど確かにそうだ!ローマ数字だと桁が増え過ぎたら辛い。
  • 植木算
    • 0のことを忘れるな!という有名な問題。0を入れ忘れるあるあるネタを植木算ということは知らなかった。
  • 対角線論法
    • どこで使えるか知らないけど、なるほどなぁー。と思った。

今後

  • 基礎的な本でも新たな気付きを得られる。基礎的な本を読むのも良い!興味持ったらまずは読んでみようと思う。
  • (30過ぎて今更ですが…)本って良いですね。他者がいくら伝えても意味がない。進んで読む気持ちを持たせる工夫が必要だと感じた。

「WebAPIアプリケーション「超」入門 FirebaseとAPIによるWeb会議システム制作」を読んで

内容

f:id:fatherofikura0107:20190322075420j:plain

このテーマを選んだ理由

  • Firebaseを触ってみたかったから

所感

初めてFirebaseやWebAPIを使う人には雰囲気を体験できる良い教材

  • タイトルにある「超」入門の通り。めちゃ駆け足。どうやって使えば良いかはなんとなーく分かるくらい。
    • ただ、開発環境のセットアップやコードの解説などはそこまで細かく記載していないので、Web開発全くしたことない人だと躓くかもと思った。
  • Realtime Databaseの凄さが良く分かる。
    • 少ないコード行数(100行程度)でRealtimeチャットが作れるなんてどうかしてる。

所々誤字がある

  • 3-3のサンプルコードが3-2と同じ。
  • FirebaseのDeployなのにinitコマンド書いてあった。
    • こちらのサイトを参考にdeployした。ファイルの中身も記載があり大変助かった。

その他

  • XAMPPあると簡単にWebサーバ建てれるので便利だが、MACだとそもそもPythonなどの開発環境入っているのでそれで代用できるっぽい。いいなぁ。
    • Apacheの設定で躓いた。が、別の勉強にて何度か設定しているので躓いても起き上がるまでが早くなった。
  • 会社で朝活している関係上、声出せないので音声認識は諦め。今後のテーマ選びは考えようと思った。
  • Realtime DatabaseとCloud Firestoreの違いはなんだろう。
    • 公式ドキュメントに書いてあった。
    • どちらもNoSQLベース。昔からあるのがRealtime Databaseのようだ。
  • @iwashi86さんがやっているSkyWay初めて触った。こんな簡単にビデオ会議のシステム作れるんだ…。裏側どうなってるんだろう…。

今後

  • Firebaseにより興味が出た。DatabaseとHostingだけだっとのでその他の機能も使ってみたい。

「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」を読んで

書籍

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める

この本を選んだ理由

  • モビングについて単純に興味がある。
  • 自チームはペアでの作業を行っており、モビングからも良い知見が得られるのでは…と思ったから。

所感

※かっこ書きは本の中の章番号。

良かった点

  • モブプロとペアプロとの違い(1.2)が書いてある。
    • ペアプロだと意見が食い違うと膠着するが、モブプロはチームなので個人を否定された感が少ない。(1.2.1)
      • 今はペアで動いているため意見の対立=個人否定になりかねない。この部分を解消できるのはモブプロの大きな意味に感じる。
    • モブプロはペアより中断しにくい。ペアだと片一方が病気、会議、電話で中断すると作業が止まる。(1.2.2)
      • 休みがちな方とペア組んでいるので分かる...凄くよく分かる…。
    • モブプロ効果測定は難しいので、コンフリクト解決、欠陥数、学習度、チームメンバーの改善効果の所感を利用すると良い。(1.3.2)
      • 確かに効果測定はどうやるのだろうか?と感じていた。モブプロやる前に測っておくべきだなぁ。得られた成功を記録しておくと上長への説明に役立つらしい。ふむふむ。
  • モビングの軌道修正方法がかかれている(4)
    • エキスパートがいる場合のモビングはタイピストではなく、モブのコーチとして知識の穴を埋める形で参加してもらうと良い(4.1.3)
    • 手探りなモビングの場合は、タイムボックスを決めて個人で探求する方法(4.2.3.1)や強いモビング(=進行役を設けアイディアは進行役に委ね、進行役からのみタイピストに依頼する)を使いバラバラの意見をまとめる(4.2.3.2)
    • 些細な仕事のモビングの場合は、無理に皆で同じ仕事をする必要はない。振り返りや体制を整えたりすればよい。(4.3.3)
      • メリハリって大事だなぁ。引き出しとして覚えておきたい。
  • モブプロの核心であるフロー効率について書かれている。(7)
    • フロー効率を表すのに高速道路の例を用いている(7.1.1)
      • 全ての車が一定スピードではないので、どこかで急ブレーキすると後ろ全体に影響を与え、いつ目的地に到着するか予測することが難しい。一方、フロー効率重視だと車間距離に余裕があり、目的地到着の予測がつきやすい。(7.1.1.1)
        • これはなるほどと思った。フロー効率の良さは目的地到着の誤差が少ないという点なのか!
    • 仕事を早く始めることが目標ではなく早く終わらせることが目標。(7.3)
      • ここがモブプロの本質のような気がする。未完成では意味がないことを皆理解すべき。
  • モブプロ実施で漠然と遅くなったと感じるのであればエンドツーエンドで考えてみるとよい。(8.2.1)
    • コードの部分だけみてもしょうがない。もっと広い視点でみれば早くなっている。モビング/ペアリングの効果を聴かれた際はこの点を意識して回答したい。

その他

  • 無駄とは何か?業務全体の効率化を考えていくとモビングという手法に落ち着いたのかなぁと個人的には思った。
  • チーム/組織として働く上で人との繋がりは大事であることを本を読むたびに感じている。