BuriKaigi2020主催参加&発表してきた

富山県では Tech系のセッションを楽しんでから、富山の本物のブリを楽しむ "BuriKaigi" という何やらコンテキストの理解が難しい名物イベントが例年冬になると開催されている。

BuriKaigi2020 & Ruby

というわけで今年もBuriKaigiが開催された。

toyama-eng.connpass.com

昨年までは一般枠で参加して、酔った勢いで軽減税率をdisるLT*1をするなど自由気ままに楽しんでいたが、今年は主催側の一人として参加した。

BuriKaigiは昨年までは、基本的にはJava系とMS系の2トラック構成だったという認識をしているが、先日開催した富山Ruby会議*2が有難いことに想像を超える大盛況となり、そこからの流れで主催のなぎせさん(@nagise)から「今回はRubyトラックもやろう」というお話を頂いた。

富山Ruby会議では自分はあくまでもメインスタッフの一人という位置付けだったので、「よーし今度は自分ががんばるぞ!」という気持ちで引き受けた。

なんやかんやあって自分も話した

富山Ruby会議はそれなりの準備期間があったので、スピーカー調整をする時間も十分にあったが、今回は引き受けてからの期間が短かったこともあり、枠をすべて埋めることができなかった。(くやしい)

そんな中、Ruby枠で発表して頂いた皆様には心より感謝しています。

最終的には25分が2枠余ったので、同じくRuby枠の調整をしていたふぁらお加藤さん@PharaohKJと私で1枠ずつ話すことにした。

話したこと

自分がそこそこ知見があるということもあり、最初はレガシー改善系の話をしようかと思ったが、つい最近のKanazawa.jsでのLTで同じネタを使ってしまい、しかも予想よりも反響があったので「さすがに同じ話をこの短期間でするのは何か負けた気がする」ということで、まったく別の話を考えることにした。

Vue.jsのwatchやらcomputedやらの仕組みを話そうかな、とかも思い浮かんだけど、参加者層的にフロントエンドの話はあんまり面白くないかもな〜と思ったのと「Ruby枠として調整してる自分が一体何を..!?」というので踏みとどまった。

最終的には、Ruby枠で話す唯一の地元富山県在住のスピーカーは私だけだな、と気づいたこともあり、せっかくなら富山に生きるエンジニアとして、ここまでの数年間を振り返ってみる話をすることにした。(結局Rubyの話をしていない

「自分の話」を発表するにあたって、資料や話すときに激しく気を使ったのが、なんというか「どうだ!すごいだろう!!」みたいな雰囲気にならないようにする点だった。

自分の話をするということは、自分が過去に何かを選択したときの話をすることになるが、それはつまり逆側の選択をしている人から見ると「それは違うだろ」と感じる可能性もある。

あくまでも "自分のここまでを振り返ったときの個人の意見です" という点に注意して、誰かを傷つけたりすることのないように、かつポジティブな内容になるよう配慮したつもりではある。

なお当初は、「なんやかんやあったけど技術書典出たら本出せて楽しかったよ!!」 的な話をしようと思ってた。ただ、資料を作ってるうちに 「別に技術書典自体が根幹にあるわけではないのでは...??」 と思い始め、自分は一体何をしたんだ..?と考えた結果を自分なりに解釈した結果、深夜に吐き出されたものとなっている。

参加者としての感想

ずっとRubyのセッションが集中しているルームCにいた。

全セッションとても楽しく聞いていたが、個人的に強い関心があったことから、直接DMを送って登壇をお願いした フィヨルドブートキャンプ @komagataさんの話がとてもよかった。富山という遠い地での登壇を快諾頂き感謝申し上げます。

ボンヤリとプログラミング教育的な部分に関心を持っていたのと、ここ最近世の中に漂うエンジニア爆アゲみたいな空気感にずっとモヤモヤしてて、それが自分だけのものなのかを確認したかったというのがあった。セッション内容だけではなく、懇親会含めてお話できて色々とスッキリした。ありがとうございました。

来年以降

BuriKaigiの運営Slackに早くも#2021チャンネルが爆誕していたので、主催者側の一人として来年も頑張ることはとりあえず確定した模様。

発表者としては、「地方エンジニアとしての話を地方でする」というのは一定の需要があるとは思っている。ただ、もし外部から要望を受けたら話すとは思うけど、自分からこういったネタを積極的に持ってくるのは暫く控えようと思う。

こういう話ばかりを続けるのは、胡散臭い自己啓発セミナーの類に近づいてしまう気がするし、そういうのじゃなくて技術的な面で発表して、間接的に地方エンジニアとしてアピールしていきたい。

もし来年も機会があれば、今度は技術ネタで登壇するぞ!と思った。

そんなことよりブリしゃぶですよ!!!

で、そんなことよりもですね!!!

今年のブリしゃぶが本当にヤバかったんですよ。

毎年BuriKaigiのブリしゃぶは絶品なのだが、今年はなんというかレベルが違った。 (なお数年前も同じ会場だったらしい)

f:id:mugi1:20200201200007j:plain
富山の地酒をすべて鍋に突っ込むという狂気

f:id:mugi1:20200201200744j:plain
着火

f:id:mugi1:20200201195428j:plain
1人前が通常の店の4人前ぐらい繰り出されるブリ

めちゃくちゃ美味しかった。 来年も楽しみです!!

地方での勉強会を4年間続けるために必要だったもの

※このエントリは 第二弾 地方IT勉強会 Advent Calendar 2019 14日目の記事です。

Toyama.rbという勉強会をはじめて4年経った

私は富山県で、Toyama.rbというコミュティを主催しており、月に1度ほどのペースでもくもく会を中心とした勉強会を開催してます。

toyamarb.github.io

現在このエントリも、もくもく会の中で書いてます。

このエントリ投稿が2019年12月で、第1回のもくもく会を開催したのが2015年の12月なので、まる4年間続けたことになります。

地方勉強会の厳しさ

地方で勉強会を続けるには様々なハードルがあります。

  • 会場の確保
    • 都会のように勉強会支援に積極的な企業は多くない
  • 参加者が少ない
    • そもそも「勉強会いくぞ!」という人の絶対数が少ない
  • ネタが続かない

勉強会をはじめたものの、続かずに消えていくケースもあるようです。

なぜ4年も続いたのかを考えてみる

いまとなっては毎月第2土曜日になると当然のようにもくもく会を開催していますが、あらためて「なんでこんなに続いたんだろう??」と考えてみると、色々と気づきがありました。

「開催する」を最優先のテーマにしていた

Toyama.rbで私が一番重要視しているのは「開催する」ことです。 他にも「できるだけ手を動かして学びたい」とかも思ってはいるのですが、大前提としては開催することに重きを置いています。

開催日時は固定化する

これはお隣である石川県のkanazawa.rbを参考にした点です。 参加者が予定をつけやすいように、開催日時を固定化しており、 Toyama.rbの場合は毎月第2土曜日の午後と決めています。

特に家族がいる場合などは、突発的に勉強会があっても予定を合わせづらいものです。

定期的に決まったサイクルで開催されていれば、参加者としてもわかりやすくなります。

とにかく「開催はしてるんで!」というスタンス

Toyama.rbの紹介をするときに「参加者が私一人だとしても会場はあるんで!」とよく言ってます。 もし私が都合がつかない場合、他のメンバーに主催をお願いして継続開催しています。 実際にはそれでも都合がつかず開催できなかったことが1〜2回ほどあったのですが、 「毎月やってるToyama.rb」というイメージが大事だと思っています。

基本的にテーマは絞らない

Toyama.rbは、基本的にもくもく会が中心です。

もくもく会って何? - NAVER まとめ

Rubyコミュニティではあるのですが、このもくもく会Rubyへの縛りは一切ありません。

f:id:mugi1:20191214135339p:plain
Toyama.rbの紹介時に使っているスライド

もちろんテーマを絞ったほうが、ディープな話ができるなどメリットもありますが、そのぶん人を集めるコストが上がります。 「なんでもオッケーですよ!」というスタンスでやってるので、わりと初心者の方も参加してくれています。

がんばらなくても開催できるようにする

もくもく会の特徴としては

  • 準備はほぼ何もいらない
  • ひとりでもやれる

といった特徴があります。とにかく会場を抑えて行けさえすれば開催できます。

これが重要で、主催者だって仕事やプライベートが慌ただしいこともありますし、 なんならあんまりやる気が出ないときだってあるでしょう。

基本的なイベントを準備が不要なものにしておくことで、「とりあえず開催する」ということも可能になります。

そんな中で、たまに色のついたイベントを混ぜることで、程よい頑張りと刺激でコミュニティを継続できていると思います。

とにかく続けたから出来ることもある

そんなこんなでゆる〜く続けてきました。

先日、初回から参加してくれている@kunitooをオーガナイザとして、富山Ruby会議が開催できました。 私はあくまでもスタッフの一人としての参加でしたが、「こういった大きいイベントをやろう」と切り出せる場を提供できていたことが何より嬉しかったです。 Toyama.rbをはじめて数回のタイミングでそういった話は現実味はなかったと思いますし、長く続けてきたからこそ実現に繋がった部分があったかな〜と(個人的に)思ってます。

まとめ

そういうわけで、地方で勉強会をやる一つの戦略として「がんばらずにとにかく開催する」という方法もあるよ、というお話でした。

次回、 第二弾 地方IT勉強会 Advent Calendar 2019 15日目は、同じく北陸である福井県のふくもく会のお話のようです。

地方勉強会としてはさらに先輩にあたるので、たのしみですね!

「レガシーフロントエンド安全改善ガイド」を商業出版します #技術書典

※2019/11/8: 無料サンプルと目次を記事内に追加しました。

f:id:mugi1:20191105233030j:plain:w400

2019年4月に開催された技術書典6で頒布した「レガシーフロントエンド安全改善ガイド」ですが、このたびインプレスR&D社さまより商業版を刊行することになりました。

自分が商業版の技術書を書く日が来るとは思わなかったのでビクビクしています。

nextpublishing.jp

表紙イラストは同人版と同様、鍋料理さんに描いていただきました。「安全な感じで!」という相談から、カワイイ工事現場が仕上がりました、とても気に入ってます。工事現場本と呼んでください。

タイトルに「迷わない!困らない!」という強気ワードが付いててちょっぴり恥ずかしいですが、迷わず困らない内容になってる・・はずです!

同人版との違い / 加筆・修正した点

紙の本で比較すると、ページ数が110ページ程度→200ページ超と大幅に加筆しています。 同人版のときは印刷費用なども怖くてあえて書かなかった部分がたくさんあったのですが、それらもすべて盛り込んだ結果、大変なことになりました。

すべてのコードをTypeScriptベースに変更

同人版では、改善後のコードはBabelを利用したESNextのコードとしており、TypeScriptについては「かなり流行ってるし、こちらもオススメだよ」程度に触れていました。

しかし、「これからレガシーフロントエンドを改善するのであれば、選択肢としてTypeScriptを無視するのはありえないだろう」と考え、すべての改善後コードをTypeScriptを前提とした形に変更しています。

結果的には、サンプルコードを含めたすべてのコードを書き直すことになって死ぬかと思いました。

TypeScript導入に関する章を追加

全コードがTypeScript前提となったので、TypeScript導入に関するセクションも追加しています。主にツラい環境への段階的な導入にフォーカスを置いています。

  • どういった設定から始めたらよいのか
  • 型定義で落ちる部分はどう対処したらいいのか
  • anyとどう向き合えばいいのか

といった、既存コードベースに導入する際に困る点を詳細に書いたつもりです。

全体的に解説部分と実践編とで分離

同人版は、一冊を通してサンプルコードをひたすら書き換えていくような内容になっていました。 これはこれで写経とかもできて楽しかったのですが、読む本としてはツラいものがあるだろうな〜と思っていました。

そこで商業版では、各章ごとに基本的な解説を用意した上で、章末尾に実践編として同人版のようなサンプルコードの書き換え例を紹介する形としています。

情報だけざっと読みたいんじゃ〜〜、という方は各章の前半部を見てもらえればOKですし、さらに深く理解したい場合には、1章ずつ実践編をこなしていくことで、同人版と同様に手を動かして書き換えの流れを追うことも可能になっています。

ESLint/Prettierの章を追加

  • そもそもなぜLintツールが必要なのか?
  • 段階的に導入するためにはどうしたらよいか?

といった点をがっつり書いています。 TypeScriptと組み合わせた場合のtypescript-eslintの導入も紹介しています。

Vue.jsに関する説明も掘り下げ

本書後半では、jQueryなどで書かれたレガシーコードからの書き換え先として、主にVue.jsを取り上げて紹介しています。

同人版ではひたすらサンプルコードを書き換えつつ紹介していましたが、レガシーコードとは根本的な考え方が異なり困惑する部分も多いかなと思ったため、簡単なモーダル表示なども例にあげつつ、同人版よりかなり掘り下げて書いています。

その他

他にもさまざまな加筆・修正が入っています。

  • パッケージ管理ってどうしたらいいのか
  • サーバサイドでレンダリングされるテンプレート依存のコードへのテストをどう書くか
  • 改善完了後にどうしたらいいか
  • などなど...

(足しすぎてもはや自分でもよくわからない)

どんな方にオススメか

次のような方が想定読者です(本書内に書いてある内容と同一です)

  • レガシーフロントエンドから脱却する現実的な方法を知りたい
  • モダンなツール・ライブラリーのメリットや導入方法を知りたい
  • 改善作業における心構えやノウハウを知りたい
  • 改善作業をしたいが何から手をつけたらよいかわからない
  • 実践的に手を動かしてモダンな技術要素を学びたい

JavaScriptを利用したフロントエンド開発における基礎的な部分の説明は省略しています。DOM などのピンと来ない場合には少し難しいかもしれません。

無料サンプル

1章までの無料サンプルです。なんとなくの雰囲気はわかるかもしれません。

目次

目次も以下に載せておきます。いっぱい書いたな..って気持ちになりました。

第1章 改善の前に 
  1.1 改善作業に伴うさまざまなリスク 
  1.2 改善で得たいものは何か? 
  1.3 「安全」な改善とは 
  1.4 リスクを軽減する 

第2章 レガシーコードを理解する 
  2.1 いきなりコードを変更しない 
  2.2 DOMの扱いで分離する
    - Write/書き込み
    - Read/読み込み
    - Event/イベントハンドリング
  2.3 理解を記録として残す 
    - 資料化して残す 
    - コードコメントに残す 
  2.4 自分の理解度を確認する 

第3章 パッケージ管理 
  3.1 手動によるパッケージ管理は大変 
    - バージョン管理のコスト 
    - 依存ライブラリーの取り扱い 
    - 環境の再現 
  3.2 パッケージマネージャー 
  3.3 npmの導入 
  3.4 dependenciesとdevDependencies 
  3.5 npxによるコマンドの実行 
  3.6 実践編:パッケージ管理 

第4章 テストコードを用意する 
  4.1 変更前の挙動をテストコードで保証する 
  4.2 E2Eテスト
    - Jest と Puppeteer による E2E テスト 
    - ブラウザーを起動して E2E テストを目視で確認する 
    - テストはモダンに書く 
  4.3 ビジュアルリグレッションテスト 
    - jest-image-snapshot 
    - threshold(しきい値)の調整 
    - reg-suit 
  4.4 スナップショットテスト(HTML)
    - HTML ベースのスナップショットテストの位置付け 
    - E2E テストの範囲 
  4.5 テンプレートがサーバーサイドに依存するケースへの対処 
    - JavaScriptのRead/Writeに注目したテストを書く
  4.6 実践編:テストコードを用意する 
    - E2Eテスト
    - ビジュアルリグレッションテスト
    - スナップショットテスト 
    - npm-scripts の登録
    - テストコードの準備完了 

第5章 ESLint/Prettier
  5.1 コードの記法による潜在的なリスク 
  5.2 人の手によるチェックの限界 
    - 見落とす 
    - 人によって好みが出る 
    - 指摘する・されることの心理的な負担
    - 解決策→機械にやらせよう! 
  5.3 ESLint 
    - ESLint の導入 
    - 公開されている ESLint 設定を流用する 
    - ESLintを少しずつ適用する 
    - 一度すべて無効にして1ルールずつ有効化する
    - --fix オプションが機能するものから対応していく 
    - 対応できない箇所 
  5.4 Prettier 
    - Prettier の導入 
    - 設定のカスタマイズ 
    - ESLint と併用する 
    - 自動整形によるコードへの影響 
  5.5 実践編:ESLint/Prettier
    - 一部ルールの無効化 
    - グローバル値への対処 
    - ESLint/Prettier の導入完了 

第6章 TypeScript
  6.1 TypeScript 
  6.2 型の恩恵 
  6.3 TypeScriptかECMAScript(Babel)か 
  6.4 完全な型定義はとても大変 
    - 最小のコストで最大の恩恵を得る
    - anyと上手に付き合う
  6.5 TypeScriptのセットアップ
    - --init で生成される tsconfig.json
    - その他の変更したほうがよいオプション
    - 最終的な tsconfig.json のサンプル
  6.6 ライブラリーの型定義 
    - 公開されている型定義を利用する
    - 独自で型定義を用意する 
    - 基本的には any で推論されるが...? 
  6.7 グローバルの値の型定義 
  6.8 TypeScript ESLint 
    - ESLint と TSLint 
    - typescript-eslintの追加と設定
  6.9 実践編:TypeScript
    - テストコードを TypeScript 化 
    - TODOアプリ本体のコードをTypeScript化 
    - TypeScript ESLintの追加
    - TypeScript 化の完了 

第7章 モジュール分割 
  7.1 小さく切り出す 
  7.2 モジュール管理とモジュールバンドラ 
    - TypeScript とモジュール管理 
  7.3 webpackのインストールと設定 
    - watchモードでwebpackを起動する
  7.4 ライブラリーをnpmパッケージへ移行する 
  7.5 コードを分割する 
  7.6 実践編:モジュール分割 
    - webpack の導入 
    - jQuery を npm パッケージ利用に置き換える
    - Read 部を切り出す 
    - Write 部を切り出す 
    - モジュール分割の完了
 
第8章 Vue.js(セットアップ) 
  8.1 DOM が中心であることのデメリット 
    - 複雑化しやすい 
    - データと HTML の関連が不明瞭 
  8.2 宣言的テンプレートと状態管理へ 
    - Vue.js 
  8.3 Vue.js のセットアップ 
    - SFC(Single File Components) 
    - SFC のビルド設定 
  8.4 Vue.js と TypeScript を組み合わせる 
    - Vue.extend 
    - クラススタイルコンポーネント 
  8.5 Vue.js DevTools 
  8.6 Vue.js の基本知識 
    - コンポーネントの基本的な構成要素
  8.7 実践編:Vue.js(セットアップ編)
    - SFC のビルド設定 
    - 動作確認 
    - Vue.js のセットアップ完了 

第9章 Vue.js(移行の予備知識) 
  9.1 移行時に発生しやすい問題 
    - イベントバインドのタイミング 
    - DOM 書き換えの競合 
    - 非同期の DOM 更新 
    - 空白文字による差異 
  9.2 目指すべき理想構成 
    - 責務の閉じたコンポーネントの集合体にする 
    - 単方向データフロー 
    - データの集約 

第10章 Vue.js(移行編)
  10.1 Read/Write/Event との対応 
    - Read 
    - Write 
    - Event
  10.2 シンプルな Write 部から切り出す 
    - コンポーネントへの切り出し 
    - Vue.js とレガシーフロントエンドコードとの連携 
  10.3 Publish/Subscribeモデル(EventBus)
    - EventBus は一時的な措置 
  10.4 Vue.observable 
    - 段階的に移行しつつデータを集約する
    - Vue.observable を安全に使う 
  10.5 Vuex 
    - Vuex を使うかどうか 
  10.6  DOM をデータで表現する 
    - 入力フォーム 
    - 連続した類似要素 
    - 表示・非表示の切り替え 
  10.7 切り出したコンポーネントに親子関係を作る 
  10.8 実践編:Vue.js(移行編) 
    - テストコードについて 
    - Write 部の切り出し 
    - Vue.observable データストアの作成 
    - DOM をデータで表現する 
    - Vue.js 化に伴う問題に対処する
    - Write 部の撤廃 
    - Read 部の Vue.js 化 
    - 単方向フローを構築して全体を整理する
    - データストアをどうする? 
    - 最終的な状態

第11章 リリースまでを安全に
  11.1 レビュワーの負担を下げる 
    - 改善作業のレビューはつらい 
    - レビューボリュームを小さくする
    - 確認してほしい観点を明確にする
    - 資料化を怠らない 
    - ペアプロ・モブプロ 
  11.2 改善するスコープを決める 
  11.3 トラブル発生時のダメージを軽減する 
    - ロールバックを想定する 
    - ピークタイムのリリースを避ける
    - 小さく進められないときにも有効

第12章 改善できた、次はどうする?
  12.1 時と共にレガシー化は進む 
  12.2 日々改善を続ける 
  12.3 機械的に改善可能な環境を整える 
    - テストコード作成の習慣化 
    - CI 環境を整える 
    - Dependabotによる依存ライブラリーの更新
  12.4 改善作業は終わらない 

というわけで...

技術書典6のときに、物理本が完売してしまって買えなかった方もいたのが心残りでした。 この本が一人でも多くのレガシーフロントエンドで悩む方の助けになれば嬉しく思います。

パワーアップした「レガシーフロントエンド安全改善ガイド」をよろしくお願いします🙏

富山Ruby会議開催前のよもやま話

f:id:mugi1:20191029234042p:plain

2019/11/03(日)に北陸初の地域Ruby会議となる、富山Ruby会議が開催されます。

toyamarb.github.io

私は主催者というわけではないですが、メインスタッフの一人としてせっせとお手伝いをしています。

富山県Rubyコミュニティが無いことを知り、Toyama.rbを始めたのが2015年の12月。そこから、小さいながらも毎月もくもく会を中心とした活動を続け、2019年10月の(台風で中止になった)活動で45回目となりました。

そんな中、第1回から参加してくれておりToyama.rbの運営にも協力してくれている @kunitoo さんが「富山で地域Ruby会議をやりたいです!」と提言してくれたので、同じく第1回から参加の @noboru_i さんと共に、メインスタッフとして支える形で開催に向けて色々と準備を進めております。

数年前はコミュニティすら存在しなかった地元富山県で、超豪華なスピーカーをお招きして地域Ruby会議を開催できることになったというのは、なかなかに感慨深いものが...

富山Ruby会議のテーマ

テーマはRubyと富山を楽しみ知ってもらう」です。

県外の方には富山を存分に楽しんでいってもらえるといいかなと思います。ブラックラーメンを食べる時だけは覚悟してから行ってください。

そして...

富山 or 北陸のかたへ

富山の方には「Ruby」そのものを知ってもらいたいと思っています。

単純にRubyというプログラミング言語を勉強していけというイベントではありません。Rubyという言語の可能性とそれを支える人やコミュニティがどういったものかを富山Ruby会議を通じて一人でも多くの方に伝えられたら嬉しいなと思ってます。

そのため、当日のセッション内容も非常に間口の広い内容になっています。

招待講演となる松本宗太郎さんの「型なし言語のための型」と伊藤淳一さんの「○○からRubyへ」の内容の違いが特に象徴的ではないかと思います。(私も超聞きたい)

主催の自分が言うのもアレですが、富山にいてこれだけのイベントを今後やれるかどうかはわからない部分もあるほど貴重な機会ですので、悩んでいる場合にはぜひ参加してみることをオススメします。

ちなみに...

もし富山を含む北陸圏の方で参加を悩んでいる方がいた場合、次のような理由なのかな〜と勝手に予想しています。

  • Ruby?普段はJava or .NET or C#しか触らないからな〜
  • 勉強会とか参加したことないしな〜
  • 会社で行けって言われる研修とかつまらないし、そんなのだろうな〜

当たらずとも遠からずではないでしょうか。 というのも、これは数年前の自分がこうだっただけで、ゴリゴリにJavaを中心とした受託の仕事をしていましたし、勉強会みたいなものは存在も知りませんでした。

それが数年たった今はRubyを使いつつリモートワーカーとして仕事をしています。(最近はTypeScriptしか書いてませんが)

色々考えてみると、今に繋がる大きなきっかけの一つは4年前に兵庫で行われたRubyプログラミングキャンプに思い切って参加してみたことです。

mugi1.hateblo.jp

勉強会に1回も参加したこともないのに、とりあえず兵庫まで乗り込むという、今考えるとぶっ飛んだ行動してるなって思う節もありますが、確実にあそこから色々人生が変わったな〜という実感もあります。

ただ「Rubyを学んだからこうなった」と直接思っているわけではないです。もちろんRubyは間接的に自分を助けてくれましたが、一番大きかったのはRuby界隈に存在する人やコミュニティの空気に触れたことで、富山にいただけでは得るのが難しい考え方や姿勢を学ぶことができたことかなと思います。

よく地方と都会でのITの技術格差みたいな話題を耳にします。 もちろん地方では勉強会も少なくてトレンドを追うだけでも一苦労ですが、何よりも「技術たのしい!!たのしい!!」みたいな空気感を浴びる機会が少ないことが一番致命的な問題に感じています。興味ない人のほうが多数派なんですよね。

私は兵庫まで行きましたが、今その刺激のある空気感が富山に来ようとしています。これは参加するしかないですね!!!

ということで、影響は小さいかもしれませんが、富山Ruby会議を通じて少しでも地元に良い影響を与えることができたら嬉しいなって思います。

そしてここからは正直な話

と、ちょっとエモいようなことを書いていい感じの話のような雰囲気を出してますが、結局のところ「細かいことはいいから富山Ruby会議参加してくれると嬉しいです!!!!」というだけなのでよろしくね!!!

toyamarb.connpass.com

ちなみに本編の参加ももちろん嬉しいですが、懇親会もぜひ参加するといいですよ!このお店のお鮨は美味しいよ!!!

toyamarb.connpass.com

※なお、懇親会会場のお店からは少なくとも30人でという話で貸切になっているところが、現状27人ほどなので、マジでこちらもみんな来てほしい。メインスタッフのお財布事情の危機かもしれない。(切実)

技術書典6で「jQuery to Vue.jsで学ぶ レガシーフロントエンド安全改善ガイド」という本を出します #技術書典

1章のみを無料サンプルとして公開しています。

タイトルのとおり、4/14の技術書典6で「jQuery to Vue.jsで学ぶ レガシーフロントエンド安全改善ガイド」という本を頒布します。

技術同人誌というものを初めて書いていますが、せっかくなら一人でも多くの方に見てもらえると嬉しいので、宣伝させてください。

f:id:mugi1:20190312232505p:plain

表紙イラストは鍋料理さん(@yaminaberyouri)に描いていただきました!めっちゃステキ。

目次

  • 1-4章 : 改善のための心構えやレガシーコードの理解、着手前の準備について
  • 5-7章 : サンプルコードをjQuery to Vue.jsに実際に書き換えていく具体例
  • 8章 : コード以外の面で改善をうまく進めていくための話

のような構成になっています。 (なお現在校正作業中なので、内容は多少変わる可能性があります。)

f:id:mugi1:20190312234156p:plain:w400 f:id:mugi1:20190312234207p:plain:w400 f:id:mugi1:20190312234218p:plain:w400

どんな内容?

表紙はとってもカワイイですが、私がここ2年ほどやってきたフロントエンドの改善経験がベースになっているため、中身はゴリゴリに現実的な話になっています。

jQuery to Vue.js とありますが、内容の本質は「安全なレガシーコードの改善」です。 安全とはデグレを減らすといった意味合いもありますが、何よりも心理的安全をどう確保しながらリファクタリングを進めるかについて、心構えや準備に加え、テストコード・コード分割・レビュー戦略など、様々な観点からのアプローチを紹介しています。

そして、jQuery to Vue.jsを実際に書き換える流れを段階的に追っていくことで実践的に学べるようになっています。

Vue.jsに限らず、流行りのフレームワーク・ライブラリを導入しようとしたときに、ゼロベースでの構築方法の情報はたくさん見つけることができますが、稼働しているリアルな現場に投入するための情報というのはあまり存在せず、実際やろうと思うとかなり苦労します。

というより、実際私がめっちゃ苦労した(している)ので、その経験から、どのようにやれば心臓をバクバクさせながらの恐怖のリリースをせずに済むのかをまとめています。

  • レガシーなフロントエンドコードに困っている・困りそう
  • フロントエンドのリファクタリングに興味がある
  • 改善作業についてのノウハウを知りたい
  • Vue.jsを導入しようと思っているがどうしたらいいかわからない
  • Vue.jsを手を動かしながら学ぶチュートリアルが欲しい

といった方にオススメです。

頒布数

現在悩み中です。100-150くらいを予定していますが、様子を見て増減したいと思います。


というわけで、よかったら当日買ってもらえると嬉しいです!

/ @mugi_uno

※なお、一瞬だけマルチカーソルの本を書こうかと思ったのは秘密です。

軽減税率制度について思うこと

ブリ会議2019の懇親会で、酔った勢いでToyama.rbの年末LT大会でやった軽減税率の話を再演した。

法律施行の10月まで使える鉄板ギャグみたいな扱いをしていて、軽減税率芸人になりつつある。が、正直なところ本当にこれはギャグみたいな話じゃないの?って思っているのも事実。

なんだかな〜?と思っている点がいくつかあるので、思考整理も含めてまとめてみたい。

注意点

私は法律の専門家でもなんでもない。ただの一般人のプログラマとしての視点で考えたときに、おかしいな〜、って思った部分を書いている。そのため、その筋のプロが見たら「それは違う」という点があるかもしれない可能性も理解している。けど、これは個人のブログなのでそういうもんだと思ってほしい。

軽減税率とは

特集-消費税の軽減税率制度 | 政府広報オンライン によると、

社会保障と税の一体改革の下、消費税率引上げに伴い、低所得者に配慮する観点から、「酒類・外食を除く飲食料品」と「定期購読契約が締結された週2回以上発行される新聞」を対象に消費税の「軽減税率制度」が実施されることになりました。

とのこと。これを前提として書いている。

対象外品目の判断基準が複雑

ニュースとかでも言われているので知ってる人も多いと思うが、対象品目の判断基準が非常にややこしい。対象外品目として挙げられているのが

だが、ケースバイケースで判断しないといけないものが非常に多い。

実際に、個別事例のQ&A資料が公開されており、80以上のケースがひとつずつ記載されている。

消費税の軽減税率制度に関するQ&A(個別事例編)|国税庁

施行前の段階ですでにこれだけのパターンが出てきているのであれば、施行後にはもっと混乱を招くのではないだろうかと思ってる。

ちなみに個人的に一番面白いと思ったのは、「映画館のポップコーンが外食かどうか?」というやつ。答えとしては

  • 基本的には8%(軽減税率対象)
  • だが、売り場の前に座席などを設けた場合には対象外になる可能性がある
    • 飲食させるためのスペースとして設けた場合には軽減税率対象外(10%)

こんなもんわかるかよって感じである。

酒類・外食などの対象外品目に該当するか?ばかり考慮されていることにそもそも違和感がある

上記の個別例の資料では、内容の殆どが「これは酒類か?」「これは外食か?」といった内容のQ&Aとなっている。

あらかじめ対象外品目の種類を設定したからだと思うが、そもそも軽減税率は大前提として低所得者に配慮する観点から」実施されるものだったと理解している。

実施するのであればそこが一番重要で、様々な判断基準の中心にならないといけないような気がしているのだが、結果としては誰が見ても「???」な判断になってしまうものが多い。

パッと思いつくようなものでも、

  • 水道水 = 飲食専用じゃないから10%(軽減税率対象外)
  • ワンコインでお店で食べる牛丼 = 外食なので10%(軽減税率対象外)
  • かぜ薬 = 10%(軽減税率対象外)
  • 超高級な食材や金箔をリッチに使ったお弁当をテイクアウト = 8%(軽減税率対象)

などがある。

低所得者に配慮する観点から」という前提で考えると明らかにおかしいのは誰が見てもわかるが、最初に「酒類・医薬品・外食・ケータリング」といった大前提を決めたうえでそこに該当するか?という判断基準ですべてを考えてしまっているため、明らかに無理が出ている。

そもそも飲食料品が軽減税率対象で8%になるが、所得が多ければそれだけ飲食料品にかけるコストも高いことが多いだろうし、それらも一律で8%になってしまうのであれば、果たして誰のための軽減なんだろう?と思ってしまう。

新聞が軽減税率対象である話

これはもうなんというか、アレですよね。

言うまでもない。

適格請求書における免税事業者の負担の話

軽減税率が施行されるのと同日に適格請求書というものが導入される。 コレ自体に関する詳しいところはここでは触れない。

適格請求書等保存方式の導入について|国税庁

だが、

  • 「適格請求書発行事業者」でなければこれは発行できない
  • 課税事業者でなければ「適格請求書発行事業者」にはなれない

という点だけは気になっていて、現状では売上が1000万以下の事業者は消費税納税が免除されるが、上記の通り、課税事業者でなければ適格請求書というものは発行できない。

これの何が問題なんだろう?という話だが、請求書を受け取った側が消費税を納税する際、仕入れにかかったぶんは控除出来るが、これが適格請求書であることが条件になる。

https://www.nta.go.jp/taxes/shiraberu/zeimokubetsu/shohi/keigenzeiritsu/pdf/300416.pdf

大企業などが従来の免税事業者から従来の請求書を受け取った場合、仕入れ分を控除できないので、本来より大きな消費税を負担して納税しないといけない、といった状態が発生する。

これは完全に損なので、免税事業者側から見ると「あっ、適格請求書発行できないなら取引やめますね」って言われて契約が終わってしまったりするかもしれない。

これはあきらかにアレなので、免税事業者も申請をすることで適格請求書発行事業者になることができるが、それはすなわち課税事業者になるということなので、今度は消費税の納税義務が発生する。

つまり、

  • 適格請求書を発行できないためのリスクを受け入れたまま免税事業者で居続ける
  • 今まで不要だった消費税の納税を行って課税事業者になる

のどちらかを迫られることになる。つらい。

結局、中小企業などが損をする形になるように見えるので、これでいいのか?と思ってしまう。

結局の所

軽減税率制度の根底にある思想とかそのものは理解できるが、現状ではなんのためにこれを実施するのか?というのがブレブレに感じるし、そのために皆が多大なるコストを払わないといけないのは割に合わない。

世の中を無駄に複雑にするのはやめてほしいな、という思いが強い。「無駄」というのが問題で、もちろんすべての事象が1か0かで表現できるとは思っていないが、1か0かに出来るものはそちらに倒したほうが、そこにかかるコストを他に使えて有益じゃないだろうか。

今の形では本来の目的である低所得者への配慮という点が満たせないだろうし、いっそのこと一律10%とかに上げてしまったほうがわかりやすいし皆幸せじゃないかなと思ってる。(それはそれでどうなんだっていう話もあるんだろうけど・・)

なおエンジニア的な話をすると、システムにおける改修コストもべらぼうに高いと思う。消費税率が5%から8%になったのとかとは違う次元。サマータイムの件も思い出すが、基本的にITわからない人たちが色々決めているんだろうな、と思うと色々と不安しかない。

以上。

なお

これを書いたのは、サマータイムなどと違って自分の仕事に直撃する人の割合が小さめなので、あんまり騒がれてはいないように感じているため、問題意識を世の中のエンジニアに一人でも共有しておきたいな、って思ったのがある。

もし意識せずマズいこと書いてて、どこかに怒られたら消します。

終わり。

マルチカーソルを使わないVSCodeはただのVSCodeだ!〜解説編〜

先日投稿した以下のエントリで、「使い方がわからない」という意見を多く頂いた。

mugi1.hateblo.jp

マルチカーソル自体の操作方法は調べれば出てくるし、事例だけ紹介しとけばええやろ、と思っていたのだが、いきなり応用のサンプルを貼りすぎてわけがわからなかったらしい。申し訳ない。

せっかくなので、基礎から含め、どういったキー入力で上記のような操作を実現しているのかを紹介したいと思う。

🔥実践!マルチカーソル / 入門編

なおmac環境です。Windowsやその他環境の方は気合で調べてください。

また、言い訳臭くて申し訳ないが、私は普段はSublime Text Keymap and Settings Importerを使っており、SublimeTextっぽいキーバインドに変えて編集している。

一旦無効にしたうえでVSCodeデフォルトの状態で一通り調べて書いたつもりだが、もし違ってるところがあったらごめん。

📝 マルチカーソルの前に...

マルチカーソルの動作例を見てるとまるで魔法のように見えるかもしれないが、結局のところ「マルチカーソルはカーソルが複数になっただけ」ということを意識するといい。

つまり、通常編集時に単一のカーソルに対して行えることはだいたいできる。正直、これが全てと言っても過言ではなく、このあとに出てくる操作は全部これを応用しただけだったりする。

特に

  • 行頭と行末への移動・選択
  • 単語単位の移動・選択

は良く使うので、そもそもこれらの操作に慣れていない場合は、まずそこから始めるといい。

f:id:mugi1:20181211194306g:plain
いろんなカーソル移動・選択

💪 基本 / マルチカーソルのつくりかた

作り方はいくつかある。状況と経験と勘で選ぶ。

選択したものと同じものを1つずつ選択する

f:id:mugi1:20181211194934g:plain
command + D で選択後にカーソルを移動・編集

command + D で選択されている文字列と同じものを片っ端から選択状態にすることが出来る。その状態からカーソル操作を行うと、全カーソルを選択位置を基準に動かせる。

選択したものと同じものを一気に選択する

f:id:mugi1:20181211195807g:plain
一気に全部選択する

command + shift + L で 一発で全部選択することもできる。

ちなみにcommand + D のときと同じだが、文字列を選択していない状態の場合はカーソル位置にある単語をそれっぽく抜いてくれる。

クリックで任意の位置にカーソルを作る

f:id:mugi1:20181211195416g:plain
マウスでぽちぽちカーソルを作る

optionを押しながらクリックするだけ。

なお、設定で editor.multiCursorModifier いじることで修飾子を変えることが出来る。私はcommand + D と同様にcommandで操作したいので、"editor.multiCursorModifier": "ctrlCmd" という設定にしている。

マウスとかトラックパッドでポチポチやっても作れる。 文字列に何の規則も無いようなところにカーソルを作るときはこちらを使う。

範囲選択の各行の末尾をカーソル化する

f:id:mugi1:20181211201007g:plain
選択範囲の各行の末尾にカーソルを作って編集する

これが最強。とにかくcommand + D とこれだけを覚えると良い。かなり応用が効く。

デフォルトだとおそらく option + shift + I でいける。

現在のカーソル位置から上下行にカーソルを作る

f:id:mugi1:20181211201634g:plain
現在のカーソル位置から下にカーソルを増やす

command + option + ↑ or ↓ でいける。

現在の位置から上下にカーソルを増やしていくこともできる。 ただ、私はあんまり使ってない。これも使いこなすと便利だと思う。


ここまでの内容を見てもらうと既にわかるかもしれないが、結局はあとはこれらを応用して編集しているだけで、たいしたことはやってない。

🔥実践!マルチカーソル / 応用編

というわけで、上記を踏まえた上で、前回のエントリで貼ったサンプルはどのように操作しているかを紹介していく。なお、他の例と操作がほぼかぶっているものや、まあ見ればわかるでしょ、というものは省略する。

JSONで書かれたキーを定数に定義

f:id:mugi1:20181211203126g:plain

command + Dで連打したあとに選択範囲を変えてコピーして貼ってるだけ。

JSONyamlなどをマルチカーソルで取り扱うには、一定の規則で入力されているものを見つけ出すのがコツだと思う。慣れると息を吸う用にできる。

上記の例の場合には、JSONのキーを抜きたいのだが、キーの後ろには大概 :':": があるので、そこを対象にマルチカーソルで選択し、選択範囲を手前側に倒すことで一気にコピーしている。

貼り付けたあとは、範囲選択から各行末尾にカーソルを作りカンマを入力している。

他のサンプルにあった、「クォートで囲まれた中身だけ抜き出す」もほぼ同じようなことをやってるだけ。

https://cdn-ak.f.st-hatena.com/images/fotolife/m/mugi1/20181209/20181209173437.gif

これも結局、it(' を command + D で選択したあとに範囲を変更してるだけなのが理解出来ると思う。

JSONの整形

f:id:mugi1:20181211210956g:plain

これもどうということはない。

  1. 最初に全行にカーソルを作成
  2. 行頭に持ってくる
  3. deleteキーで改行を削除

とすることで一行に整形している。複数行に戻す場合には、

  1. 要素の区切りの , を選択
  2. Enterキーを叩く

とすることで一気に改行できる。

行の追加・削除的なことと組み合わせだすと混乱しがちだが、使いこなせるととても便利。

クエリを書くとき(選択範囲のマージについて)

「クエリを書くとき」は、ほぼここまでの応用なので省略したいが、一点特徴的な挙動があり、マルチカーソルは選択範囲が重なると合体して1つになる。

f:id:mugi1:20181211212315g:plain
選択範囲が合体してカーソルが1つに戻る様子

これを利用することでこんなことが可能になる。

f:id:mugi1:20181211212819g:plain
CSVから1列目だけ残してあとは消す

前エントリの、テーブル定義的なものをペーストしたあとに論理名だけ残るように削除しているのはこれを利用している。

いい感じに全部のケース変換をする

f:id:mugi1:20181211214545g:plain
一気にスネークケースに変換する

command + shift + P でコマンドパレットを開けるが、これをマルチカーソル状態から開いているだけ。あとはここまでの応用でできる。


ざっくりこんな感じ。

あとは「全行にデバッグログを突っ込む」が見た目としては派手な感じがあるが、ここまでのを見てくれたのであれば、それほど難しいことはやってないのはわかると思う。

まとめ

というわけで、ざっとコマンド付きのGifを撮り直して一通り説明を書いてみた。(つかれた..)

他のエディタでもマルチカーソルが使えるのであれば似たようなことが可能で、微妙に違いはあれども操作の勘所とかも同じはず。

あとは自分で調べたり試したりしてマルチカーソルライフをエンジョイしてほしい。

最後に、わりと書くの頑張ったので良かったらTwitterフォローしてやってください。 twitter.com

おわり。