別にしんどくないブログ

技術のことや読書メモを書いています

Vuexをスナップショットテストするパッケージを公開しました

www.npmjs.com

表題の通り、新しくnpmにVuexをスナップショットテストするパッケージを公開しました。

何するもの?

Vuexのstoreに対してactionsやmutationsの発火前後のstateの状態のdiffをとったsnapshotファイルが生成され、スナップショットテストを行うことができます。

READMEに書いているサンプルコードを載せておきます。
テストに馴染みのある方はなんとなく雰囲気を掴んでもらえると思います。

import snapshot from "vuex-snapshot-test";
import store from "@/store";

snapshot({
  store, // state: 1
  dispatches: [dispatch => dispatch("increment")]
});

上記のテストコードを実行すると以下のsnapshotファイルが生成されます。

exports[`increment 1`] = `
"Snapshot Diff:
- Before
+ After

  Object {
    \\"counter\\": Object {
-     \\"value\\": 1,
+     \\"value\\": 2,
    },
  }"
`;

まだまだ拙い箇所が散見されると思いますが、とりあえず想定通りの動作をするようになったので公開しました。 TypeScriptはサポートしています。

Thanks!

少しVuex用に工夫をしたけども、アイデアはReduxのreducerをテストするreducer-testerから頂いています。 @akamecoさんありがとうございます。

www.npmjs.com

Reduxを使った開発をしているときにreducer-testerを使っていて体験として良かったので、Vuex用を作ってみました。

予告

これをネタに今月末のv-kansaiにLT登壇します。 元気があればQiitaにも技術詳細など書きたいと思います。

vuekansai.connpass.com

フィードバックはどんどん募集しています!
ご意見、要望はIssueTwitterまでお願いいたします。

僕ができないこと 2019年版

エンジニアを数年やっているとある一定レベルから自分がどれくらいスキルアップしているのか、本当にスキルアップしているのかわからなくなることがあります。
仕事や興味を持ったことに対して調べてコード書いてとしているので、知っていることや経験は日々増えていると思います。
しかし、どういったスキルが身についたかをチェックできておらず漠然と不安があります。

そこで、自分もスキルの棚卸しと毎年スキルアップできているのかを確認するためにもできないことを書き残しておきたいと思います。
内容に関しては、エンジニアとしてあった方がいいだろうなと思うことに絞り込んでいます。
完全に個人的なことなので、興味ない方はそっと閉じていただければ・・・。
手助けできることがあるかもしれないと思う優しい方はさらっと目を通して勉強方法やオススメの本などアドバイスいただけると嬉しいです。

続きを読む

『学びを結果に変えるアウトプット大全』を読んだ

学びを結果に変えるアウトプット大全 (Sanctuary books)

学びを結果に変えるアウトプット大全 (Sanctuary books)

ノウハウだけでなく、アウトプットする時にどういったところを意識すると効果が高くなるかを理論的に説明した良い本だった。
同じテーマの他の本と重複する内容もあるが、著者の知識や経験談だけでなく理論に基づく説明が多かったのが好印象でした。

特に気になった箇所をメモしておきたいと思います。

インプットとアウトプットの黄金比は3:7

インプットの量を3、アウトプットの量を7とすることを著者は勧めています。
例えば、勉強するときも参考書を読むより問題集を解くことを中心に勉強した方が効果があるとのことです。 アウトプット駆動で勉強することは効果が高いと感じます。
興味のある分野の勉強会があればLT参加を先に決めてしまったり、資格取得などゴールがあればSNSで公言してしまってやらざるを得ない状況にするのがオススメです。 読書感想文を書くこともオススメです。読書するときもブログを書くつもりで読むと質の高い読書ができるのではないかと思います。

タイピングより手で書くほうが脳への定着率が高い

手書きの方が脳が活性化されることはあると他の本でも度々述べられているので非常に信憑性は高いと思います。
この本でも手書きとタイピングでどちらが脳への定着率が良いか研究したところ、手書きの方が定着率が高いという研究結果が記されています。

最近は共有する必要がない自分用のメモや、自分の脳の中にあるものをバーっとブレストする時は手書きするようになりました。もしくは音声入力を使ってます。思いついたことをメモするには手書きか音声入力の方が効率的に感じます。
共有が必要なことがわかっている場合は、共有しやすいタイピング入力を使います。なので、使い分けが必要だと思います。
あと、手書きしてもすぐに棄てるメモは電子メモを使っています。紙に書いて破り捨ててもいいのですが、ボタンひとつで消せるのは便利です。

非言語コミュニケーション、内容ではなく身だしなみや表情などの視覚情報、声の大きさや質などの聴覚情報も重要。話すときは内容に自信がなくても笑顔で堂々と話すように心がける

カンファレンスや勉強会の登壇者で話が上手な方は全員非言語コミュニケーションが上手だと感じます。
非言語コミュニケーションに関して、最近は登壇するときは「なるべく聴講者の方を見て話す」「大きな声で話す」「大切なところは声の大きさや間のとり方に注意する」「明るく話す」ことを心がけるようにしています。

速く文章を書く

技術記事やブログ書こうと思ってもなかなか筆が進まないことが多かったです。また書き始めても完成するまで時間がかかりました。
これを何とかしたいと思ったことがこの本を読むきっかけでした。
2つコツがあります。

時間を決めて書く

速く文章を書く1つ目のコツは時間を決めて書くことだと本には書かれています。例えば、1記事を30分で書くと制限といったことです。最初は難しいですが、脳がトレーニングされていき最終的には質の高い短文を書けるようになるとのことです。 これに関しては愛聴しているPodcast PHPの現場の24回目でも話されていてこれは参考になると思いました。

しかし、実践しても大幅に時間オーバーするので修行が足らないのか見積もりが甘いのか何か間違っていると感じているので改善策を考えないと・・・と考えています。

構成を決めてから書く

2つ目のコツは、文章を書き始める前に構成を考えると3〜4倍速く書けるようになると著者は述べています。 これは僕の実感ですが、構成を決めずに書くと一貫性が保てないことが多いと思います。
先にアジェンダやまとめを先に書くだけでも効果があると思います。

プレゼンテーション資料を作る

先に構成を決めることに似ていますが、スライドを作成する前に全体の構成を手書きで作ってしまう方法です。
先日の登壇資料を作成するときに実践してみましたが、これは結構良い方法でした。
これまでアジェンダとまとめを最初に書くようにしていましたが、全体構成をざっくりきめてしまうと資料作成のときに一貫性を保つことができます。
具体的には1ページを4分割します。発表時間が60分の場合は15分ずつ4分割した紙に話したいことを時計回りにざっくり書いていきます。

字が汚い&写真写りが悪いので見苦しいかもしれませんが、前述した電子メモに記載したときのプレゼンテーションの構成です。

f:id:Shisama:20190203190631j:plain
Denoについて発表したときの資料作成の前に書いた構成図

読書感想文を書く

読んだ本の読書感想文をブログとして書くことで記憶の定着率や読解力が上がります。このエントリのように実践しやすいアウトプットだと思います。

要約を140文字で書く

Twitterです。読んだ本や読んだ記事などのインプットを140文字で要約します。要約力を高めるために良いアウトプット実践だと思いました。

最後に

手で書くことの効果と非言語コミュニケーションの大切さをこの本から学ぶことができました。
この本に記載されていることは科学的根拠を用いた説明が多いので信憑性があると言えます。
本の構成上、気になるところだけ読んでも学ぶことができるように工夫されています。また図や絵なども載っているのでイメージもしやすいと思います。
アウトプットが出来ていなくて悩んでいる方やアウトプットの質を高めたいと考えている方にはオススメできる本です。

最後までお読みいただきありがとうございました。オススメの本やこのエントリに関するご意見はTwitterまたははてなブックマークにてお願いいたします。

登壇前のスライド公開はメリットしかなかった

関西Node学園 5時限目 - connpassで登壇したのですが、今回は登壇前にスライドを公開してブログに貼りTwitterでも告知しました。
これはid:Soudaiさんがいつも登壇する時にされていることです。いつも登壇前にスライドを公開しておられます。
builderscon 2018に参加したときに先にブログでスライドを読んでから実際話を聞いても全然新鮮さを損ねている感じがしませんでした。もちろんそーだいさんの話が上手なのもあると思います。しかし、先にスライドを読んでいたことで話が頭に入ってきやすかった感覚を覚えています。

soudai.hatenablog.com

今回の発表に話を戻します。
今回の発表内容はまだ多くの方が知らないDenoについての話だったので「本当に楽しんでもらえるのか」や、まだ僕も経験が少ないので「間違っているところはないか」と少し不安がありました。
もしかすると何かフィードバックもらえるかもしれないと思い、そこで先に公開して反応を見てみることにしました。

すると、こんな反応がありました。

フィードバックいただきました!!
しかも、お二方ともDenoの開発をめちゃくちゃやっている方々だったので、非常に自信に繋がりました。また、発表前にご指摘いただけたり新しい情報を共有していただき助かりました。

「こんなものか」「Denoの話、楽しみにしてたけど全部知ってるからキャンセルしよう」とか思われるかもしれない、と公開前は不安が少しありましたが結果としては公開するデメリットは一つもなかったですし、メリットしかなかったです。

今後も登壇前にできるだけスライドを公開したいと考えています。
スライドが登壇ギリギリまで完成していない時は厳しいかもしれませんが、そもそもそうならないように余裕を持って資料作成を行わなければ!(と自分に言い聞かせています)

最後までお読みいただきありがとうございました。もし他にも登壇前にこういうことすると良いよなど勉強会やカンファレンス登壇についてアドバイスがあればTwitter宛までご共有いただけると嬉しいです!

『関西Node学園 5時限目』を開催しました #kng5

nodejs.connpass.com

2019年最初の関西Node学園はサイボウズ大阪オフィス様で開催させていただきました。
サイボウズの岡田さん、榎原さん、太田さんありがとうございました。

今回は自分も登壇しました。
最近Denoのコードを読んだりコントリビュートし始めたのと、最初ryが発表した頃から中身も変わっていてGoからRustに書き換えられていたり、 日本でもDenoのモジュールを開発している人やコアにコントリビュートしている人も増えてきたので、話をしたら楽しんでもらえるかもしれないと考えました。

shisama.hatenablog.com

他のセッションもすべて面白かったです。
今回は知らないことが多く、自分も非常に勉強になりました。 (恥ずかしいですが、分散データの話とか全然ついていけませんでした・・・)

資料に関しては以下のconnpassのページにまとめています。

nodejs.connpass.com

すべてのセッションが終わって片付けしながら、終了予定時刻まで時間が少しあったので、その間に参加者と登壇者の方々が交流していたことが嬉しかったです。
Denoについても質問いただけたので、とても嬉しかったです。
登壇してフィードバックもらえることは嬉しいし、登壇した甲斐があったなと感じます。 参加者の中には「質問して大丈夫かな」「変なこと聞いたら失礼かな」などためらう方も多いかと思いますが、多くの登壇者はどんなフィードバックでも嬉しいと思うので、どんどん質問や感想をするとお互いにとっても良いかと思います。また、そういったことができるのがオフラインでの勉強会の良いところだと思います。

また、終了後に@zilch8@Ajido@leichtgewichtと小規模懇親会として飲みに行きました。
そこでもとても楽しい時間を過ごしました。

次回の開催ですが、4月末か5月始めころにNode.js v12がリリースされるのでその付近で開催できたらいいなと考えています。
登壇者と会場提供してくださる方を絶賛募集しています。

では次回もよろしくお願いいたします!

f:id:Shisama:20190202155428j:plain
懇親会で食べた肉盛り合わせ

関西Node学園 5時限目でDenoの話をします #kng5 #denoland

表題の通り、2019-02-01に主催している関西Node学園でDenoについて話をします。 現状僕が知っていることを話します。 Coreのコードについても話したいですが、時間の都合上割愛する予定です。

スライドは発表までに修正するかもしれません。

speakerdeck.com

質問や不備はTwitterブコメでお願いいたします。 間違いは特にメンション飛ばして教えてほしいです。

blink-devのススメ。Chromeの最新動向キャッチアップについて

最近、情報収集の一環で新しく始めたことがあるので紹介したいと思います。

blink-dev

知っている人も多いかもしれないですが、blink-devというchromiumレンダリングエンジンBlinkに関するグループが存在します。

https://groups.google.com/a/chromium.org/forum/#!forum/blink-dev

ここではBlinkの機能や仕様について活発に議論がされています。 このグループは誰でも参加可能で、誰でも投稿することができます。

このグループのフォーラムを眺めているとchromiumの最新の情報を得ることができます。 すべての情報をキャッチアップするのは大変ですが、ここでは僕がなるべくやるようにしていることを紹介したいと思います。

Intents

上記のblink-devのページを開いてもらうとわかると思いますが、各投稿はIntent to 〜というタイトルになっています。Intentは意思とか意図とかって意味だそうです。 そのIntentsにも種類があります。

  • intent to Prototype: explainerや仕様、設計が書かれている(Idea phase)(design phase)
  • intent to experiment: Origin Trialなど試験運用がされる(Implementation Phase)
  • intent to implement: 実装が始まったもの(Implementation Phase)
  • intent to ship: stableに入る(Implementation Phase)
  • intent to remove: 削除される機能 などがあります。

そもそも多すぎてタイトルだけでも確認するのが大変なので、intent to shipまたはintent to implement and shipだけ見ることもあります。

chromiumのプロセスについては以下に書かれています。

dev.chromium.org

メールで確認する

興味のある内容は抑えておく

このグループのメンバーになると投稿があるとメールで通知が来ます。毎日結構な数が来るので、すべて見ているわけではないですが興味のあるタイトルは概要だけでも読むようにします。
内容をちゃんと読みたい場合はページを開いて議論の内容も見ます。

知らないけど気になる内容も見てみる

タイトルを見て知らないけど気になったメールも見るようにしています。
メールを見てまったく興味がわかない場合もありますが、その場合はアーカイブして終わりです。
知らない単語が出てくることも多いですが、その都度調べることで新しいことを学ぶことができます。

無知で恥ずかしいですが、最近知ったのはCross-Origin-Resource-Policyです。

他のグループ

blink-dev以外にもchromiumに関するグループはあります。 例えばdevtools-devやChromium-devがあります。全く投稿が無いグループもありますが、グループ名から興味のあるグループを覗いてみるといいと思います。

https://groups.google.com/a/chromium.org

他のブラウザ

自分はChromium派生ブラウザを使うことが多いのと(良し悪しありますが)ブラウザの進歩をリードしているのはChromiiumだと考えているので、他のブラウザについては全く見ていません。
しかし、他のブラウザでも最新情報を追う方法はあります。
Jxckさんが配信しているmozaic.fmでは毎月Webの最新動向を配信するMonthly Webがあるのですが、それを聞くと毎月の最新情報はキャッチアップできます。
Jxckさん自身がどうやってキャッチアップしているかというのは以下のエントリにまとめてくださっています。僕もこのエントリを読んでblink-devを知りました。

blog.jxck.io

このエントリに書かれているように他のブラウザでも最新の情報を能動的に得る方法はあります。

また、ChromeにCanaryがあるようにFirefoxにはNightlyがあり、SafariにはTechnical Preview版があります。それらを使ってみたり、CHANGELOGを追うのもいいかもしれません。

今回は最新のChromiumの情報を得るために行っていることを紹介しました。
最後までお読みいただきありがとうございました。質問や不備などがありましたらTwitterまたははてブとかでコメントしてもらえるとキャッチアップできると思います。