v-kansai Vue.js/Nuxt.js meetup #3で発表します。
当日までに書き換えるかもしれませんが、フィードバックいただけると嬉しいです。
資料の中で紹介しているvuex-snapshot-testのGitHub、npmはこちらから
v-kansai Vue.js/Nuxt.js meetup #3で発表します。
当日までに書き換えるかもしれませんが、フィードバックいただけると嬉しいです。
資料の中で紹介しているvuex-snapshot-testのGitHub、npmはこちらから
表題の通り、新しく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はサポートしています。
少しVuex用に工夫をしたけども、アイデアはReduxのreducerをテストするreducer-testerから頂いています。 @akamecoさんありがとうございます。
Reduxを使った開発をしているときにreducer-testerを使っていて体験として良かったので、Vuex用を作ってみました。
これをネタに今月末のv-kansaiにLT登壇します。 元気があればQiitaにも技術詳細など書きたいと思います。
エンジニアを数年やっているとある一定レベルから自分がどれくらいスキルアップしているのか、本当にスキルアップしているのかわからなくなることがあります。
仕事や興味を持ったことに対して調べてコード書いてとしているので、知っていることや経験は日々増えていると思います。
しかし、どういったスキルが身についたかをチェックできておらず漠然と不安があります。
そこで、自分もスキルの棚卸しと毎年スキルアップできているのかを確認するためにもできないことを書き残しておきたいと思います。
内容に関しては、エンジニアとしてあった方がいいだろうなと思うことに絞り込んでいます。
完全に個人的なことなので、興味ない方はそっと閉じていただければ・・・。
手助けできることがあるかもしれないと思う優しい方はさらっと目を通して勉強方法やオススメの本などアドバイスいただけると嬉しいです。
学びを結果に変えるアウトプット大全 (Sanctuary books)
ノウハウだけでなく、アウトプットする時にどういったところを意識すると効果が高くなるかを理論的に説明した良い本だった。
同じテーマの他の本と重複する内容もあるが、著者の知識や経験談だけでなく理論に基づく説明が多かったのが好印象でした。
特に気になった箇所をメモしておきたいと思います。
インプットの量を3、アウトプットの量を7とすることを著者は勧めています。
例えば、勉強するときも参考書を読むより問題集を解くことを中心に勉強した方が効果があるとのことです。
アウトプット駆動で勉強することは効果が高いと感じます。
興味のある分野の勉強会があればLT参加を先に決めてしまったり、資格取得などゴールがあればSNSで公言してしまってやらざるを得ない状況にするのがオススメです。
読書感想文を書くこともオススメです。読書するときもブログを書くつもりで読むと質の高い読書ができるのではないかと思います。
手書きの方が脳が活性化されることはあると他の本でも度々述べられているので非常に信憑性は高いと思います。
この本でも手書きとタイピングでどちらが脳への定着率が良いか研究したところ、手書きの方が定着率が高いという研究結果が記されています。
最近は共有する必要がない自分用のメモや、自分の脳の中にあるものをバーっとブレストする時は手書きするようになりました。もしくは音声入力を使ってます。思いついたことをメモするには手書きか音声入力の方が効率的に感じます。
共有が必要なことがわかっている場合は、共有しやすいタイピング入力を使います。なので、使い分けが必要だと思います。
あと、手書きしてもすぐに棄てるメモは電子メモを使っています。紙に書いて破り捨ててもいいのですが、ボタンひとつで消せるのは便利です。
カンファレンスや勉強会の登壇者で話が上手な方は全員非言語コミュニケーションが上手だと感じます。
非言語コミュニケーションに関して、最近は登壇するときは「なるべく聴講者の方を見て話す」「大きな声で話す」「大切なところは声の大きさや間のとり方に注意する」「明るく話す」ことを心がけるようにしています。
技術記事やブログ書こうと思ってもなかなか筆が進まないことが多かったです。また書き始めても完成するまで時間がかかりました。
これを何とかしたいと思ったことがこの本を読むきっかけでした。
2つコツがあります。
速く文章を書く1つ目のコツは時間を決めて書くことだと本には書かれています。例えば、1記事を30分で書くと制限といったことです。最初は難しいですが、脳がトレーニングされていき最終的には質の高い短文を書けるようになるとのことです。 これに関しては愛聴しているPodcast PHPの現場の24回目でも話されていてこれは参考になると思いました。
#phpgenba で話してた書く時間を決めてブログを書こうとやってみた。まあ、時間どおりでは無かったけど、日付は変わらなかったから良しとしよう。 https://t.co/rUpizLCiki
— Masashi Shinbara (@shin1x1) 2018年11月15日
しかし、実践しても大幅に時間オーバーするので修行が足らないのか見積もりが甘いのか何か間違っていると感じているので改善策を考えないと・・・と考えています。
2つ目のコツは、文章を書き始める前に構成を考えると3〜4倍速く書けるようになると著者は述べています。
これは僕の実感ですが、構成を決めずに書くと一貫性が保てないことが多いと思います。
先にアジェンダやまとめを先に書くだけでも効果があると思います。
先に構成を決めることに似ていますが、スライドを作成する前に全体の構成を手書きで作ってしまう方法です。
先日の登壇資料を作成するときに実践してみましたが、これは結構良い方法でした。
これまでアジェンダとまとめを最初に書くようにしていましたが、全体構成をざっくりきめてしまうと資料作成のときに一貫性を保つことができます。
具体的には1ページを4分割します。発表時間が60分の場合は15分ずつ4分割した紙に話したいことを時計回りにざっくり書いていきます。
字が汚い&写真写りが悪いので見苦しいかもしれませんが、前述した電子メモに記載したときのプレゼンテーションの構成です。
読んだ本の読書感想文をブログとして書くことで記憶の定着率や読解力が上がります。このエントリのように実践しやすいアウトプットだと思います。
Twitterです。読んだ本や読んだ記事などのインプットを140文字で要約します。要約力を高めるために良いアウトプット実践だと思いました。
手で書くことの効果と非言語コミュニケーションの大切さをこの本から学ぶことができました。
この本に記載されていることは科学的根拠を用いた説明が多いので信憑性があると言えます。
本の構成上、気になるところだけ読んでも学ぶことができるように工夫されています。また図や絵なども載っているのでイメージもしやすいと思います。
アウトプットが出来ていなくて悩んでいる方やアウトプットの質を高めたいと考えている方にはオススメできる本です。
最後までお読みいただきありがとうございました。オススメの本やこのエントリに関するご意見はTwitterまたははてなブックマークにてお願いいたします。
関西Node学園 5時限目 - connpassで登壇したのですが、今回は登壇前にスライドを公開してブログに貼りTwitterでも告知しました。
これはid:Soudaiさんがいつも登壇する時にされていることです。いつも登壇前にスライドを公開しておられます。
builderscon 2018に参加したときに先にブログでスライドを読んでから実際話を聞いても全然新鮮さを損ねている感じがしませんでした。もちろんそーだいさんの話が上手なのもあると思います。しかし、先にスライドを読んでいたことで話が頭に入ってきやすかった感覚を覚えています。
今回の発表に話を戻します。
今回の発表内容はまだ多くの方が知らないDenoについての話だったので「本当に楽しんでもらえるのか」や、まだ僕も経験が少ないので「間違っているところはないか」と少し不安がありました。
もしかすると何かフィードバックもらえるかもしれないと思い、そこで先に公開して反応を見てみることにしました。
はてなブログに投稿しました #はてなブログ
— Masashi Hirano (@shisama_) 2019年1月31日
関西Node学園 5時限目でDenoの話をします #kng5 #denoland - 別にしんどくないブログhttps://t.co/JVbMM8snt6
すると、こんな反応がありました。
関西Node学園行きたくなった / 1件のコメント https://t.co/pglY5JHDqn “関西Node学園 5時限目でDenoの話をします #kng5 #denoland - 別にしんどくないブログ” (1 user) https://t.co/7ZB7kMT2ew
— しゅーまい (@__syumai) February 1, 2019
スライド素晴らしいと思いました!! 👏✨ install script ですが、最近は sh 版が出来て、こちらの方が推奨ぽいです。あと、privileged が数カ所 privilleged になっているのが気になりました。Internal Design の図で最近ちょっと update されたバージョンがあったりします https://t.co/5Z4VB3qKQu
— Yoshiya / ひのさわ / かた(肩) (@kt3k) February 1, 2019
フィードバックいただきました!!
しかも、お二方ともDenoの開発をめちゃくちゃやっている方々だったので、非常に自信に繋がりました。また、発表前にご指摘いただけたり新しい情報を共有していただき助かりました。
「こんなものか」「Denoの話、楽しみにしてたけど全部知ってるからキャンセルしよう」とか思われるかもしれない、と公開前は不安が少しありましたが結果としては公開するデメリットは一つもなかったですし、メリットしかなかったです。
今後も登壇前にできるだけスライドを公開したいと考えています。
スライドが登壇ギリギリまで完成していない時は厳しいかもしれませんが、そもそもそうならないように余裕を持って資料作成を行わなければ!(と自分に言い聞かせています)
最後までお読みいただきありがとうございました。もし他にも登壇前にこういうことすると良いよなど勉強会やカンファレンス登壇についてアドバイスがあればTwitter宛までご共有いただけると嬉しいです!
2019年最初の関西Node学園はサイボウズ大阪オフィス様で開催させていただきました。
サイボウズの岡田さん、榎原さん、太田さんありがとうございました。
今回は自分も登壇しました。
最近Denoのコードを読んだりコントリビュートし始めたのと、最初ryが発表した頃から中身も変わっていてGoからRustに書き換えられていたり、 日本でもDenoのモジュールを開発している人やコアにコントリビュートしている人も増えてきたので、話をしたら楽しんでもらえるかもしれないと考えました。
他のセッションもすべて面白かったです。
今回は知らないことが多く、自分も非常に勉強になりました。
(恥ずかしいですが、分散データの話とか全然ついていけませんでした・・・)
資料に関しては以下のconnpassのページにまとめています。
すべてのセッションが終わって片付けしながら、終了予定時刻まで時間が少しあったので、その間に参加者と登壇者の方々が交流していたことが嬉しかったです。
Denoについても質問いただけたので、とても嬉しかったです。
登壇してフィードバックもらえることは嬉しいし、登壇した甲斐があったなと感じます。
参加者の中には「質問して大丈夫かな」「変なこと聞いたら失礼かな」などためらう方も多いかと思いますが、多くの登壇者はどんなフィードバックでも嬉しいと思うので、どんどん質問や感想をするとお互いにとっても良いかと思います。また、そういったことができるのがオフラインでの勉強会の良いところだと思います。
また、終了後に@zilch8、@Ajido、@leichtgewichtと小規模懇親会として飲みに行きました。
そこでもとても楽しい時間を過ごしました。
次回の開催ですが、4月末か5月始めころにNode.js v12がリリースされるのでその付近で開催できたらいいなと考えています。
登壇者と会場提供してくださる方を絶賛募集しています。
では次回もよろしくお願いいたします!
表題の通り、2019-02-01に主催している関西Node学園でDenoについて話をします。 現状僕が知っていることを話します。 Coreのコードについても話したいですが、時間の都合上割愛する予定です。
スライドは発表までに修正するかもしれません。