blog/10 | ikuma-t.com

Appraisalを使っている状態でもRubyMineのGUIでRSpecを実行する

2022/2/9

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220209/20220209071635.png🔗

きっかけ
TL:DR;
前提のおさらい
- Appraisal
- RubyMineでのRSpec実行
問題点
対応策
scriptを作成する
RubyMineにscriptを認識させる
実行結果
感想

きっかけ

github.com🔗

先日開発したGemはActiveRecordへの対応を仕様として盛り込んでいるため、Appraisalを使って、複数verのActiveRecordでテストができるようにしています。

それはそれでいいんですが、この状態でいつものようにRubyMine上からテストを実行しようとすると、Appraisalで指定しているはずのGem（ActiveRecord）がないためにテストが落ちるようになってしまいました（ActiveRecordからAppraisal経由でテストをすれば問題なくとおる）。

Testing started at 7:13 ...An error occurred while loading spec_helper. - Did you mean?                    rspec ./spec/spec_helper.rbFailure/Error: require "active_record"LoadError:  cannot load such file -- active_record# ./spec/spec_helper.rb:6:in `require'# ./spec/spec_helper.rb:6:in `<top (required)>'Run options: include {:full_description=>/JpLocalGov\.find/}All examples were filtered out

というわけで今回はAppraisalを経由しても、RubyMine上でテストを実行できるようにしていきます。

TL:DR;

Apppraisalを導入する場合、各種コマンドはbundle exec appraisalの形式で呼び出す必要がある。
RubyMine標準のRSpec実行はbundle exec rspec …. であるため、Appraisalが導入されていて、そこでインストールされたGemに依存する実装・テストを書いている場合、RubyMine経由でRSpecが実行できなくなる。
AppraisalのCLIを経由するscriptを作成し、RubyMineに設定することで、RubyMine経由でもRSpecを個別に実行できるようになる。

前提のおさらい

Appraisal

Appraisalはthoutbot社が管理している、複数のバージョンでのテストを同時に行うためのGemです。

github.com🔗

公式READMEからの拝借になりますが、以下のように指定することで、Railsの3と4の双方の環境でテストを実行することができます。通常のGemfileでは1つのGemに対して、1つのバージョンしか指定できないため、複数環境に対応したい場合に重宝します。

appraise "rails-3" do  gem "rails", "3.2.14"endappraise "rails-4" do  gem "rails", "4.0.0"end

Appraisalを使用する場合、各種コマンドは次のように実行することになります。

bundle exec appraisal {実行対象の環境} <実行したいコマンド># 上記例で、rails-3のかんきょうでテストしたい場合、bundle exec appraisal rails-3 rspec

RubyMineでのRSpec実行

f:id:ikmbear:20220209071635p:plain

RubyMineではテスティングGUIに関係なく、GUI上でテストの実行ができます。

一括実行と個別実行の双方を行うことができます。

内部的には、各テスティング$1のexampleやname指定のオプションなどを付与しながら、bundle exec rspecを実行しているだけです。

問題点

上記の通り、Apppraisalはbundle exec appraisalの形式で各コマンドを呼び出すことで、指定した環境のGemfileでコマンドを実行することができます。

逆にいえばAppraisalを経由しないと、Appraisalで指定したGemfileは認識されません。冒頭に述べた通り、Appraisalは複数のバージョンでのテストを可能にするためのGemなので、Appraisalを経由しない = テストが実行できないということです。

RubyMineでのテスト実行はAppraisalを経由しない形式になっているので、結果としてAppraisalを利用すると、テストが実行できないということになります。

対応策

以下の2ステップで対応します。

Appraisal経由でテストを実行するscriptを作成する
1のscriptをRubyMineに認識させる。

scriptを作成する

github.com🔗

require 'rubygems'require 'bundler/setup'require 'appraisal'require 'appraisal/cli'begin appraisal_name = ''rails-5.0" # this is just an example, use the appraisal that you have installed  cmd = [appraisal_name, 'rspec'] + ARGV  Appraisal::CLI.start(cmd)rescue Appraisal::AppraisalsNotFound => e  puts e.message  exit 127end

AppraisalのIssueを確認していると、同じような問題が起票されていました。

AppraisalにCLIがあるので、それを間接的に呼び出すようです。このコードでは特定のAppraisal環境をしていするようになっていますが、とりあえずすべてのAppraisal環境で実行するように少し修正しました。

require "rubygems"require "bundler/setup"require "appraisal"require "appraisal/cli"begin  `bundle exec appraisal list`.split(/\R/) do |appraisal_name|    cmd = [appraisal_name, "rspec"] + ARGV    Appraisal::CLI.start(cmd)  endrescue Appraisal::AppraisalsNotFound => e  puts e.message  exit 127end

RubyMineにscriptを認識させる

RubyMineのGUI実行は、それぞれ実行の構成を指定することができます。

zenn.dev🔗

f:id:ikmbear:20220209071725p:plain

複数の構成に対して、まとめて設定を行うためには「Edit configuration templates…」を選択します。

f:id:ikmbear:20220209071741p:plain

左側のサイドバーからRSpecを選択し、「Use cutom RSpec runner script」に、1で作成したscriptを設定します。scriptはどこにおいてもいいですが、Appraisalはプロジェクト固有のものだと思うので、私はプロジェクトのbinフォルダにおいています。

これにより、RubyMineがRSpecを実行するときは、このコマンドを実行するようになります。

実行結果

BUNDLE_GEMFILE=/Users/tadokoroikuma/RubymineProjects/jp_local_gov/gemfiles/rails61.gemfile bundle exec rspec

これらの設定でRSpec実行時にAppraisalのCLIが走るようになり、Gemfileを指定した状態でテストが実行できるようになりました。

感想

Appraisalで作成した環境に対してCLI実行する分にはこのCLIでいいんですが、「ある特定のテストを特定の環境でのみ実行したい」というケースは対応できないので、対応できるようにしておきたいです（CLIの引数処理→Appraisal CLIの引数処理の部分だけクリアできれば、ちゃちゃっとできると思うので）。

Appraisalを使っている状態でもRubyMineのGUIでRSpecを実行する

公開日: 2022/2/9

Conventional CommitでGemのCHANGELOGをコミットから自動作成する

2022/2/8

に公開

Conventional Commitとは

概要

Gitのコミット粒度はまずConventional Commitsで種類が混ざりにくいようにしつつ、「小さいコミットを後からくっつけたり並べ替えたりする方が、大きいコミットを後から分割するよりもずっと簡単なので、迷ったら細かくコミットして後から見直せばいいよ」とよく言っていますhttps://t.co/ySrZSP2xQ7🔗

— Takuto Wada (@t_wada) 2021年12月3日🔗

t_wadaさんが以前Twitterで言及されているのを見かけて、Conventional Commitなるものがあることを知りました。

Conventional Commitとは、以下のようなコミットメッセージの規約を指します。

Conventional Commits の仕様はコミットメッセージのための軽量の規約です。明示的なコミット履歴を作成するための簡単なルールを提供します。この規則に従うことで自動化ツールの導入を簡単にします。コミットメッセージで機能追加・修正・破壊的変更などを説明することで、この規約は **SemVer🔗**と協調動作します。

引用元：https://www.conventionalcommits.org/ja/v1.0.0/🔗

形式

Conventional Commitは以下の形式を取ります。

<型>[任意 スコープ]: <タイトル>[任意 本文][任意 フッター]

型はfeatやfix、docsなど、変更を端的に表した単語です。具体的には次のようになります。

feat(subscribe): メール購読解約時のログインを不要にしたユーザーのストレス軽減のため（適当）Closes: #79

RubyMineでのサポート

www.conventionalcommits.org🔗

にもある通り、Conventional Commitをサポートするためのツールはかなりたくさんあります。所詮はコミットメッセージなので、人力で入力してもConventional Commitにはできるのですが、型やフッターを選択肢から選べたり、枠が決まっているので形式を意識せずにメッセージを作れたりするので、あった方が何かと便利です。

このページにもInteliJ用のツールは掲載されているのですが、私は別途「Conventional Commit」というツールを使っています（RubyMineのPluginストアで評価が高いのを選んだだけ）。

plugins.jetbrains.com🔗

Conventional CommitでCHANGELOGを作る

で、ここからが今回の本題で、Conventional CommitからCHANGELOGを作成します。

何故-conventional-commits-を使うのか🔗 には、理由の1つに

• 変更履歴 (CHANGELOG) を自動的に生成できます。

とあって、どうやって自動生成できるのかなと思ったんですが、コミットメッセージが規約に則っていることで、別途ツールを使用すればCHANGELOGにCHANGELOGが作成できるということのようです。

今回は以前リリースしたGemのCHANGELOGを作成してみることにしました。

conventional-changelog

Conventional Commitから色々やるためのツールが、conventional-changelogとしてまとまっています。

github.com🔗

この中のconventional-changelog-cliを使用してCHANGELOGを作成します。

github.com🔗

インストール

conventional-changelog-cliはnpmなので、まずはインストールします。

リリースのためだけに$1を汚したくないので、グローバルインストールします（グローバルを汚すのはいいんかい）。

$ npm i -g conventional-changelog-cli

コマンド

conventional-changelog コマンドで実行します。helpを見ると分かる通り、結構色々なオプションがあります。

$ conventional-changelog --help  Generate a changelog from git metadata  Usage    conventional-changelog  Example    conventional-changelog -i CHANGELOG.md --same-file  Options    -i, --infile              Read the CHANGELOG from this file    -o, --outfile             Write the CHANGELOG to this file                              If unspecified, it prints to stdout    -s, --same-file           Outputting to the infile so you don't need to specify the same file as outfile    -p, --preset              Name of the preset you want to use. Must be one of the following:                              angular, atom, codemirror, conventionalcommits, ember, eslint, express, jquery or jshint    -k, --pkg                 A filepath of where your package.json is located                              Default is the closest package.json from cwd    -a, --append              Should the newer release be appended to the older release                              Default: false    -r, --release-count       How many releases to be generated from the latest                              If 0, the whole changelog will be regenerated and the outfile will be overwritten                              Default: 1    --skip-unstable           If given, unstable tags will be skipped, e.g., x.x.x-alpha.1, x.x.x-rc.2    -u, --output-unreleased   Output unreleased changelog    -v, --verbose             Verbose output. Use this for debugging                              Default: false    -n, --config              A filepath of your config script                              Example of a config script: https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-cli/test/fixtures/config.js    -c, --context             A filepath of a json that is used to define template variables    -l, --lerna-package       Generate a changelog for a specific lerna package (:[email protected])    -t, --tag-prefix          Tag prefix to consider when reading the tags    --commit-path             Generate a changelog scoped to a specific directory

実際に作ってみる

conventional-changelog -p eslint -i CHANGELOG.md -s

今回はESLint形式で、CHANGELOG.mdに対して追記をしていきます（なんでESLintにしたかというと、ESLintが一番よく知っているパッケージだからというだけです、すみません😅）。

このコマンドを実行してできたCHANGELOGがコチラになります。

# [](https://github.com/IkumaTadokoro/jp_local_gov/compare/v0.1.0...v0.) (2022-01-14)### chore* Add RSpec Runner for JetBrains IDE ([83d8c86](https://github.com/IkumaTadokoro/jp_local_gov/commit/83d8c8649f69506c9a08acf275960480316eb988))* Make JpLocalGov::Data::Importer#prefecture_capital? to return true/false ([82daafd](https://github.com/IkumaTadokoro/jp_local_gov/commit/82daafd19b47e52ff2c1c341a243aef7e5dffae4))### ci* Add spell checking GitHub Actions Workflow ([fc23bd1](https://github.com/IkumaTadokoro/jp_local_gov/commit/fc23bd1a3c10cc49f8aaf4e869c0062b50255f03))### docs* 💅 ([61c6d66](https://github.com/IkumaTadokoro/jp_local_gov/commit/61c6d66a43b75339036656a1b110dec97156177e))* Add how to use JpLocalGov.valid_code? ([2e14d71](https://github.com/IkumaTadokoro/jp_local_gov/commit/2e14d71c146d823e4bc3fa268da2e3a0c5f7ebe1))* Add issue template ([9f416a3](https://github.com/IkumaTadokoro/jp_local_gov/commit/9f416a335247c3be5c52e450b914bd73c380092d)), closes [#47](https://github.com/IkumaTadokoro/jp_local_gov/issues/47)

Closing Keyword🔗 を使ってIssueをクローズしていると、参照先のIssueも表示されるみたいです。これは結構便利ですね。

PRをもらった場合にどうするか？

そのOSSにコミットする人がみんなConventional Commitを使うかというとOSSの場合はそうもいかないと思います。

私も実際にそのケースに出くわしたのですが、「今回は特例で手動でCHANGELOGを追加するか」ということで、特に調べず終わってしまいました。

で、この記事を執筆する過程で調べてみたところ、以下の記述が見つかりました。

www.conventionalcommits.org🔗

いいえ！ Git で squash ベースのワークフローを使用する場合は、主要メンテナがマージ時にコミットメッセージをクリーンアップすることができるため、臨時のコミッタには作業負荷がかかりません。また、これをするための一般的な方法としては、プルリク$1トからのコミットを git システムが自動的に squash し、主要メンテナによるマージ時に適切な git コミットメッセージを入力するためのフォームを表示するというものです。

Conventional Commit側の主張は、「メンテナが都度直せばいいじゃん」とのことでした…。他のRailsとかどうしているんだろう？それこそRailsのような大きなRailsだとなかなか難しいと思うんですが。

感想

というわけでConventional Commitで自動的にCHANGELOGを作る方法でした。

個人的にはコマンド1つでCHANGELOGが完成するので、気楽にupdate作業をできていい感じです。

PRのマージコミットメッセージの件も含めて、他のOSSがどんな感じにCHANGELOGを書いているのかがすごい気になったのですが、残念ながら作成する過程は見えないので、地域rbとかで聞けたら聞いてみようと思います。

余談：もう少しコミットは細かく積もうかな

少しずれるのですが、最近ちょっと前に以下の動画を見た影響もあって、「できるだけコミットはsquashしておこう」と強く意識しすぎていました。

🔗

www.youtube.com🔗

そうすると、なかなかコミットが打てなくて作業的には辛いので、

作業時はconventional commitでこまめにコミットを打つ
Pushするときにsquashする

みたいなフローにしたほうがいいなと記事を書いていて思いました。

Conventional CommitでGemのCHANGELOGをコミットから自動作成する

公開日: 2022/2/8

スマホ中毒改善のために空き箱でスマホケースを作る

2022/2/5

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220205/20220205090821.jpg🔗

$1をついつい触ってしまう…

勉強中もそうなんですが、ベッドにも$1を持ち込んでしまって、色々と質を落としているのが最近の問題点でした。

毎週1回、個人のGKPTを振り返っていて、この問題に対しては以下のような議論がなされました。

$1を金庫に入れれば良いのでは？
- 休憩中にすぐ見られない。
- しまうのと出すのが億劫になって結局継続できなさそう
$1を触らない、持っていかないという鉄の意志を持つ
- 意志の力に頼るのは根本的解決にならない
$1の定位置を机の上にもうけるのはどうだろう？
- 見える位置にあると結局触る
- 視覚的に見えない位置に収納すると良いのでは？
- あまり遠い場所に置くと、$1をなくす問題が発生する
机の近くで、かつ見えにくい位置にシュッとしまえるケースがあれば捗りそう

捗りそう…！？

で、プロトタイプ作ってみた

f:id:ikmbear:20220205090821j:plain

というわけでプロトタイプ作成です。イメージ図はこんな感じ。

右利き & モニターの右側にMacを置いているので、机の左側面にMacケースを作れると、「離着席時にはMacがよく見え、作業時には視界に入らない」という感じにできそう、っていう魂胆です。

f:id:ikmbear:20220205090831j:plain

次は材料探し。プロトタイプってことで家にある材料を探したら、FILCOのキーキャップの空き箱がありました。これを使います。

f:id:ikmbear:20220205090840j:plain

開いてほしい方向と、実際に箱が開く方向があべこべだったので、カッターで無理やりくり抜きました。不器用なんで辛かった…。

f:id:ikmbear:20220205090849j:plain

机に接着して完成です。両面テープも家にはなかったんで、ビニールテープでHOT LIMITにしています。

いざ装填！

f:id:ikmbear:20220205090858j:plain

設計通り、$1がシュッと入りました！

目論見通り、作業中は左側に全然意識が向かず、$1を触る時間が格段に減りました。びっくりするほどに睡眠の質もめちゃくちゃ上がりました！$1恐るべし…。

一つ難点があるとすれば、貼り付けがあまりにも適当すぎるので、定期的に押さえつける必要があることくらいでしょうか。

やっぱり人間ってのは定位置が決まっていると、うまく整理・整頓できるもんですね。$1の片付けが言っている「姿置き」ってやつですね。

🔗

[図解]トヨタの片づけ🔗

作者:$1
$1

Amazon🔗

このプロトタイプでしばらく持ちそうですが、HOT LIMITが解放されてしまったら、ちゃんとしたの作ろうと思います。

わたしがRubyMineを使う理由

2022/2/3

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220203/20220203082003.png🔗

f:id:ikmbear:20220203082003p:plain

「RubyMineの何がいいのか？」という問い

みなさんRubyMine使っていますか？昨今のエディタシェアでは、やはりVSCodeが一番大きなパイを占めているような感じですが、私はRubyMineが好きなのでずっとRubyMineを使っています（一部例外で、LiveShareを使いたいとか、Slidevのスライドを作る時だけVSCodeを使っています）。

そんな中、FJORD BOOT CAMPで「みんながおすすめするのでRubyMine使ってみたけど、他のエディタに比べて何がいいんだろう」という質問が出てきました。

というわけで今回は一利用者として「私がRubyMineを使う理由」を述べてみました。

世界中の開発者体験が機能として実装されている

VSCodeもかなり便利ですよね。VSCodeを追加していけば「RubyMineではこんなことできるよ」の大多数はVSCodeでもできると思います。これはVimやEmacsを使った場合でも同じで、つまりフルパワー状態の単純な機能比較によっては、普段使用していて馴染んでいるエディタにRubyMineが勝る点はあまりないかもしれません。

ではRubyMineを使用するメリットは何かというと 「世界中の開発者体験が、あらかじめ機能として実装されていること」 です。

たしかにVSCodeにVSCodeを追加すれば、RubyMine相当の機能を動かせるかもしれませんが、それはその機能にあなたが 「気がついた」 場合です。使えたら便利だけど読むには細かいGitコマンドのオプションや、DBの操作方法の全てに気がつくことができるでしょうか？少なくとも私には難しそうです。

RubyMineを運営するJetBrains社は毎年開発者に対して調査🔗を実施し、製品開発のためにJetBrains製のエディタのドッグフーディング🔗を行なっています。これによりRubyMineには、世界中の開発者が「これは開発によく使うし、あると便利」と思っている機能が最初から、つまり 「気がつかなくても」 使えるようになっているわけです。

1人で学習を進めているいまだからこそ、私は世界中の開発者の動きを学習の補助輪とするために、RubyMineを使用しています。

コマンド操作が全部「見える」から

RubyMineの操作は基本的にすべてGUI上で実行されます。

そのため、コマンドで実行すると複雑な操作も、実際にどういうことをやっているのかイメージがつきやすいです。

例えばGitのrebase は最たる例で、よくわからないけど必要だから…と$1上でやると、「なんかよくわかんない…」「変な感じで取り込まれてしまった…」となりがちです。

Untitled f:id:ikmbear:20220203071125p:plain

これをRubyMine上でやると、すべてを画面操作として実行できるので、

実際にどういう作業ができるのか
今自分が行った操作はどのような結果になるのか

が画面上で確認できるため、そのコマンドでできること、自分がやっていることのイメージがしやすくなります。いわばRubyMineが各コマンドの「図解！〇〇」的な役割を担うわけですね。

もちろんGUI→CUIへの変換は必要になりますが、コマンドの実行イメージがあるおかげで、CUIで実行する際にも意図通りに実行しやすくなり、実行への恐怖感も薄れます。

はじめこそ、ちゃんと整備された道具を使ったほうがいい

私は高校時代に初めてギターにさわり、パン作りを始めました。

ギターの方は安いアコギを買ってしまったがために、弦高が高くてしばらくバレーコードが弾けなかったのですが、友達の高いギターはとても弾きやすくて、それを借りて練習しているうちに、安い方のアコギでもバレーコードが弾けるようになりました。

パン作りの方はずっと独学でやっていたのですが、大学時代にアルバイトで実際に製パンをやらせてもらえることになり、そのときに初めて整備された環境でパンを作ったことで、一気にパン作りのコツを掴むことができました。4年分の成長が3日で追い越されるくらいのブレイクスルーでした。

双方の話に通じるのは、「初めから整備された環境でやっていれば、もっと早く成長できたのに」ということです。何も最高級の環境を整えろというわけではありませんが、最初のうちは**「どんな道具が必要か」**がわからず「正しい型」もわかっていない状態です。

そんな状態だからこそ、はじめのうちこそRubyのためのフルマネージドなIDEであるRubyMineを使うのがいいんじゃないかなと思っています。

「弘法筆を選ばず」と言いますが、そもそも弘法って達人の域の話なので、個人的には「初めのうちは筆を選んでいけ」という気持ちです。

おわりに

というわけで今回は「私がRubyMineを使う理由」をお届けしました。

私自身も初学者であるがゆえに、全体的に初学者向けの内容になってしまいました（ある程度プログラミングできる人は、自分の欲しい機能とか開発スタイルでエディタを選ぶ気がするんだ…）。

speakerdeck.com🔗

以前FJORD BOOT CAMPの中で行われたLT会でも「初心者こそ！RubyMineで始めよう！」という話をさせていただきましたが、やはり最適化された開発フローをエディタを通じて学べるからこそ、自分のようなエンジニア未経験者でもお金を払ってRubyMineを使用する価値はあると思っています。

とはいえ、エディタってやっぱりエンジニアの道具の中で一番大きい部分なので、最後は「自分が使いたいエディタ」で楽しく開発するのがいいんじゃないですかね、と雑にしめて終わりにしたいと思います。

宣伝：RubyMine入門は無料で読めます！

この記事を読んで、「RubyMine使ってみようかな…でも使いこなせるか不安…」と思った方、ZennでRubyMine入門という無料で読める$1を出しています！

zenn.dev🔗

基本的な操作からGit、エディタの見た目変更まで、RubyMine初心者に必要な内容を詰め込んだ一冊になっているので、ぜひに！

OSS gateにビギナーとして参加しました！

2022/1/30

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220130/20220130112941.png🔗

f:id:ikmbear:20220130112941p:plain

昨日 OSS Gateオンラインワークショップ🔗 にビギナーとして参加してきました！

OSS Gateとは？（引用）

「OSS Gate」とはOSS開発に参加していない人が参加する人に変わる「入り口」を提供する取り組みです。

OSS開発に未参加の人向けに参加方法を伝える場を継続的に提供することにより、OSS開発に参加する人を増やすことができるのではないか。それを実現することが「OSS Gate」という取り組みの目的です。

参考：OSS Gateへようこそ！🔗

oss-gate.doorkeeper.jp🔗

参加した理由

OSS Gateのアンケートには一つだけ書いたんですが、よくよく考えると3つくらいありました。

いつもOSSにお世話になっているので、自分もそこに貢献したいと思ったから
2020年にCOVID-19のサイトがOSSとして作成された時に、自分はIT業界で働いているのに何もできなくて、ちゃんと勉強して社会の役に立ちたいと思ったことが原点の一つとしてあるから
（OSSに限らず）不満に対して文句を言うんじゃなくて、それを改善できるように生きていきたいと思っている。そのための手段としてプログラミングを学び始めたから

というような思いが常々あって、でもやっぱり見ず知らずの人にパッチとかIssueを送るのはちょっと気がひけるので、背中を押してもらうために参加しました。

作業内容

イベント自体は10:30〜17:00まで、そのうち手を動かしている時間は11:00~15:00すぎくらいまででした（途中で休憩あり）。

今回はオンライン開催だったので、Discord上で作業を進めました。作業ログを見て適宜サポーターさんから$1 & 後述の作業ログのコメントで「いいですね〜」「こういうところを見てみるのもいいかも」みたいなサポートをもらいつつ進める感じです。

作業内容としては、貢献したいOSSを選んで、それを公式のドキュメントに則って動かす中で改善した方がいいこと、エラーになったことを投げるという形式だったので、私は最近利用したMarkdownを使ってスライドが作れるツールのSlidevを対象にすることにしました。

github.com🔗

OSS Gateの特徴として、作業中は常に作業ログを取っていきます。実際に私が取った作業ログはこんな感じです。

github.com🔗

以前、「ログ駆動開発」というテーマでLTを行ったことがあって、自分も普段から作業時は全部ログを書いているんですが、これに似ているかな〜とか思いました。

ikmbear.hatenablog.com🔗

成果物

作成したIssue

というわけで実際に投げたIssueがこちらになります！

f:id:ikmbear:20220130111402p:plain

github.com🔗

Slidevには作成したスライドのExport機能があって、これがplaywright-chromiumというパッケージに依存しています。

これがない場合には、コマンド側はnpm i playwright-chromiumをするように例外を投げるのですが、一方でドキュメントにはnpm i -D playwright-chromium、つまりdevDependenciesとして追加をするように推奨していて齟齬があり、ここを統一した方がいいのでは？というIssueを立てました。

サポーターさんにも👍をいただいたポイントなのですが、この2つの文言が追加された経緯をGit Blameで辿っていけたのがよかったです。

遡っていくと、これらの文言は全く同じコミットで追加されていることがわかり、「書き間違いというか表記揺れかな？」と思えたことが主張の安心材料になりました。

気づき

午前中にさわっていた時は「エラーにはなったけど、別にログを見ればわかるからここはフィードバックポイントじゃないかな〜」と思っていたんですけど、サポーターのDaipomさんとPiroさんが書いていただいたコメントから、間接的にですが「あれ？案内している文言が違うかも」と気がつくことができました。自分でやるときはちょっとでも「ん？」と思ったところは一旦視点を変えて見つめ直すのがいいかな〜と思いました！

あとはIssueの下書きが出来上がった際に、「やっていないことを書いてみると文意が伝わりやすくなるかも」「こういう返答も想定されるので、自分のお気持ちも書いておくといいかも」といったアド$1をもらうことができました。前にkoicさんの動画でみたと思うんですが、「なぜそれを取り込む必要があるのか」「そのための判断材料」を意識して書いていくのがやっぱり大切なんだと、自分でやってみて感じました✍️

前提知識として何が必要か？

「OSSを動かした際のポイントをフィードバックする」というプログラムなので、そのOSSに対してめちゃくちゃ詳しくないといけないということはないかな〜という印象です。

技術的な前提としては

Git / GitHubが使える
黒い画面が使える

ってところですかね。実際私も、ブラウザでドキュメント読む→ターミナルでインストールする→ブラウザ上でIssueを立てるって感じでした。

あとは対象となるOSSを自分で決める必要があるので、最近使ったアプリをちょっと思い出しておくといいかもです（私は当日ふと頭に出たのでSlidevにしましたが、Gemとかでもよかったかも）。なおOSSかどうか、Issueをたてるポイントがありそうかは、プログラムの中で確認するので事前チェックは不要です。

感想

参加する前は「本当にこの時間内でIssueを立てられるのかな？」と内心不安だったんですが、本当に立てることができて、驚き & とても嬉しかったです！

OSS Gateの目的として「自分1人でもOSSに参加できるようになる（気持ちになる）」という点があるのですが、今回実際にIssueを立てることでこれからもやっていけそうだな！と感じました。

（…実際にOSS Gate終了後に今回扱ったSlidevの別件の対応の準備を始めました💪）

OSS貢献へのあと一歩が踏み出せなかった理由に「こんなんで大丈夫なのかな？」という気持ちがきっとあったのですが、今回サポーターの皆さんに自分のやっていることを「承認」してもらえたり、「客観視」した上でアドOSSをもらえたことで、自分1人の中に沈み込んでいた不安が大きく開けた気持になりました！

今回の挑戦をステップに、どんどんOSSの世界を楽しみたいと思えるイベントでした！サポートいただいた皆さん、ありがとうございました！！！！😊

余談

…当日Piroさんに言えなかったんですけど、「シス管系女子全部持ってます！初めてLinuxの勉強する時に買いました！」とここに書き残しておきます😅

f:id:ikmbear:20220130111448p:plain

おわりに：次回OSS Gateのご案内と気になる方へ

OSS Gateは定期的に開催されていて次回は3/8みたいです。

oss-gate.doorkeeper.jp🔗

参加できるサポーター枠によって、ビギナーとして参加できる方の数も変わってくるのですが、ビギナーには「サポーターを1人以上連れてくるビギナー」枠があります。

「サポーターを1人以上連れてくるビギナー」枠

今回のワークショップに「サポーター」で参加する人を見つけ、自分は「ビギナー」で参加する枠です。

実際に「サポーター」の登録者が1人増えたら繰り上がります。

どの「サポーター」がどの「サポーターを1人以上連れてくるビギナー」に対応しているかはわからないので一番最初に登録していた「サポーターを1人以上連れてくるビギナー」が繰り上がります。

もし「OSS Gate興味あるけど、枠もいっぱいだし…」という方がいたら、次回開催に限らず、お声がけいただければサポーターとして参加しようと思うので、コメント欄でもTwitterでもお気軽にご連絡ください！

OSS gateにビギナーとして参加しました！

公開日: 2022/1/30

⚡️K-Rubyと銀座Railsで自作Gemの話をしました！⚡️

2022/1/28

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220128/20220128104136.png🔗

自作Gemの話をしてきました！
プロモーション活動の成果
登壇してみて感じたこと
自分の中の発表に関するQ&A
チャンスを掴む握力も才能って杉江さんが言ってる
銀座RailsもK-RubyもLT枠募集中みたいです！
おわりに

自作Gemの話をしてきました！

K-Rubyと銀座Railsで先日作成した自作Gemの話をしてきました！

ikmbear.hatenablog.com🔗

ginza-rails.connpass.com🔗

k-ruby.connpass.com🔗

登壇資料はこちらです。Rails青緑みたいになってます（そこは赤じゃないのかよ：銀座Railsの赤にしようと思ったけど、全面赤は目に良くないのでやめた）

こっちがK-Ruby

speakerdeck.com🔗

こっちが銀座Rails

speakerdeck.com🔗

同じことを話しているので、ベースは同じなんですが、ちょっとだけまとめの方向性が違います。

K-Rubyの方は過去のイベントの登壇資料の感じから「自分の学習成果を発表する」っていうところに重点を置いていると感じたので、感想はあっさり目に、自分が工夫したところを多めに話しています。
銀座Railsの方は初のLT枠募集で、初心者の自分が貢献できるのは「エンジニア未満の人でも気軽にLT登壇していいんだ」という気持ちにプッシュするというところだと思ったので、「初心者の気持ち」に重点を置いてまとめています。

プロモーション活動の成果

github.com🔗

気持ち的には「こういうところでの発表もチャレンジしよう！（そして登壇者特典のパーカーもらおう）」というライトな気持ちで参加したのですが、Gemの方に実利的なフィードバックもあったので、さっくりご紹介しようと思います。

$1のStarが2個増えました（ありがとうございますありがとうございます🙇‍♂️）
修正のPRをいただけました！Ruby 3.0以降をサポートしていたのですが、2.7からサポートできるようになりました（リリースはまだです）
yasulabさんから地方公共団体コードを実際に使っている事例🔗を教えていただけました！継続メンテのモチベーションにすごい繋がりました！

登壇してみて感じたこと

いろいろな方に発表そのものとGemについてフィードバックをもらえたのが嬉しかったです！やっぱり言わないと伝わらないな〜とあらためて感じました！

あとは銀座Railsの懇親会に初めて参加できたのも嬉しかったです！

今までは「懇親会って緊張するし、パスかな」と思って参加したことがなかったのですが、「発表した」っていうある種の免罪符的なものがあったので、参加することができました。

懇親会ではRubyの書き方でワイワイできたり、Railsガイドの裏側の話とかが聞けてすごく楽しかったです。発表内容と被りますけど、Rubyっていう言語を介してつながりが広がっていく感じがとても心地よかったです！

…あとアンケートは毎回ちゃんと書こうと思いました😅

自分の中の発表に関するQ&A

今回発表するときにはもうあんまり感じていなかったのですが、今まで、LTという短い枠とはいえ登壇にあたって色々と気にしていたことを3点書きます。「登壇したいけど…」と思っている方の参考になれば…！

※あくまで一個人の意見です。

自己PRはあさましいか？

発表すること自体に「エゴ感強くない？」と感じるかどうかって話ですけど、全然そんなことないと思います。

私の場合、前職では部署内で数少ない若手であるがゆえに、自己PRをしていなくても、能力の如何にもかかわらず、勝手に注目されたんですよね。だからなのかちょっと自己PRをわざわざすることに少し抵抗がありました。

でも、自分はこれからエンジニアとして再スタートを切ろうとしているわけだし、突出した能力があるわけでもないので、新卒はおろか、それより前からプログラミングをやっていた人に対しては大幅にハンディキャップがあるわけですよね。

そんな状態で、企業側に「なんかいい感じに頑張れるから雇ってくれよ」ってのも無理があるし、そもそも見つけてももらえないと思っているので、最近では「外に発信することが礼儀」くらいの感じで個人としては捉えています。

…みたいな話をもっとちゃんと書いている有名な記事を貼っておきます✍️

blog.jnito.com🔗

初心者が話して迷惑じゃないか？

いろんな人が聞いている場ほど、「自分なんかの発表で時間とってしまって申し訳ない」と思ってしまいがちですが、そんなことはないと思います。とりあえずそういう気持ちがあればちゃんと練習とか資料とか考えると思いますし。

「経験者」の人には「初心者」の意見は新鮮だと思いますし、同じ「初心者」の人には共感がもらえると思います。

また「初心者」って一口に言っても、Rubyは同一ではないので、同じことをやってもその人だけの切り口があります（今回の発表だと、仮に同じようにGemを作った話だとしても、心理学者のRubyと「たのしい開発スタートアップRuby」が同時に出てくる発表がカブる確立は限りなく低いはずです）。

あとはRubyコミュニティはやっぱり優しいので、初心者でも大丈夫って感じでしょうか。

私は気にしいなので、「初心者だけど優しく受け入れてくれ」っていう無償の優しさを求めるだけなのは抵抗があって、最近はRubyistHotlinks読んだり、Rubyistの人の古い本買ったりして読んで勉強させてもらってます（なので発表に「たのしい開発スタートアップRuby」が出てくるわけですが😅）。そういう気持ちのやわらげ方もありかもです。

同じことを何度も言うのは申し訳ないか？

今回のGemの発表は短期間に2つの場所でLTをやっていて、さらにFJORD BOOT CAMP内の自作サービス進捗報告会でもちょいちょい言っているので、なんとな〜く心のどっかで「みんな知っている話をするのは申し訳ない感じするな〜」と思っていました。

実際に聞いている方がどう思われているかは別として、個人としては

発表者$1たらずっとその内容を考えていて、その流れの一つに発表があるけど、聞いている人的には別に発表の瞬間しかその内容に触れないので、重複感はそこまでないのでは？
人は結構覚えていないものなので、大事なことは何度も言った方がいい（何度も言わないと伝わらない）
プレゼンは「誰に」「何を」伝えたいかってのが骨子にあると思っていて、客層が変われば「誰に」が変わるので、そこらへんを意識して話し方とか情報の濃淡に手を加えると自分でも安心感が出るのでは？

とか考えて別にいいんじゃないかな〜と思うようにしました。

チャンスを掴む握力も才能って杉江さんが言ってる

f:id:ikmbear:20220128104136p:plain

SHIROBAKOっていう人生のバイブルみたいなアニメがあるんですが、その中で杉江さんがこんな言葉を言っています。

僕は才能っていうのはなによりまずチャンスをつかむ握力と失敗から学べる冷静さだと思う。絵の上手い下手はその次だ。僕は僕より上手い人間がわずかな自意識過剰やつまらない遠慮のせいでチャンスをとりこぼしてきたのを何度も見た。惜しいと思うよ。未だにね。———SHIROBAKO #22 ノアは下着です！より

「チャンス」の定義は難しいですけど、個人的には「いつかやってみたい」と思ったことをやる機会があるなら、それはまさしく「チャンス」だと思います。

私はアウトプット文化が好きということもあって、こういう発表をやってみたいと常々感じていたので、今回のチャンスを掴めたのはとてもよかったです！！

銀座RailsもK-RubyもLT枠募集中みたいです！

ちょっと硬いことも書いちゃいましたが、LTはコミュニティでのコミュニケーションのきっかけにもなるし、そこからいろんな人とRubyのこと、それ以外のことも含めて話せるのは楽しいので、この記事が読んでいただいた方のLT参加モチベーションアップに繋がると嬉しいです！

k-ruby.connpass.com🔗

ginza-rails.connpass.com🔗

次回の銀座RailsもK-RubyもまだLT枠を募集しているみたいなのでリンク貼っておきます！

…あと最近はまたコロナが復活してきてオンライン開催が多いですが、オンラインで発表すると、100人に話しても5人に話しても感覚的に変わらないので、いいかもしれません。

（Youtubeにあがっている過去のRuby関連のオフラインイベント見てると、リアルタイムでリアクションがあっていいなあと思ったりしますが）

おわりに

というわけでLT登壇レポでした。

LT自体は初めてではなくて、FJORD BOOT CAMP内でやっている「初めてのLT会」で2回、練習の機会をいただいていました。その時の参加レポはこちら

ikmbear.hatenablog.com🔗

こちらの記事でも書きましたが、初めての『初めてのLT会』に参加する際には、FJORD BOOT CAMP内のいろんな人に勇気をもらいました。あらためて感謝感謝です🙏

ikmbear.hatenablog.com🔗

今後も「出ない神本より出るクソ本」の精神でアウトプットの敷居を下げつつ、もっと意欲的に学習して、技術的にも、聞いていただけるみなさんのプラスになるような登壇ができるように頑張っていきたいと思います！

⚡️K-Rubyと銀座Railsで自作Gemの話をしました！⚡️

公開日: 2022/1/28

日本の地方公共団体コードをパースするGemをリリースしました

2022/1/18

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20220118/20220118162141.png🔗

f:id:ikmbear:20220118162141p:plain

作ったもの

f:id:ikmbear:20220118162056p:plain

jp_local_govという日本の$1コードを市区町村の情報にパースしてくれるGemを作りました。人生初Gemリリースです🎉

github.com🔗

rubygems.org🔗

「そもそも$1コードってなんやねん」方も多いと思いますが、

$1（ぜんこくちほうこうきょうだんたいコード）[注釈 1]🔗は、日本🔗の地方公共団体🔗につけられた、数字3桁🔗または5桁または6桁の符号（コード）である。コードが与えられる$1とは、都道府県🔗・市町村🔗・特別区🔗、一部事務組合🔗・地方開発事業団🔗・広域連合🔗、加えて、$1ではないが行政区🔗・東京都区部🔗である。

全国地方公共団体コード - Wikipedia🔗

というものです。JIS規格にも指定されています。

3桁、5桁、6桁とありますが、ルール的には

上2桁が$1府県、
続く3桁が市区町村
残りの1桁がチェックディジット

になっているので、このGemでは6桁フルの状態をパースできるようになっています。

READMEにも書いているのですが、jp_prefectureのア$1に多大に影響を受けています。

github.com🔗

作った背景

今作っているサービスで必要だったからです。

ざっくりいうと公共料金を計算するサービスで、その計算のための料率が市区町村ごとに違うために、市区町村ごとにレコードを持つ必要がありました。

で、市区町村だけのテーブルをもつのもなんだか微妙だし、市区町村のための管理画面をもつのも面倒だったので、「Gemでできないかな〜」と思っていたのですが、似たようなア$1のGemは更新が数年前…。

…みたいなことを、FJORD BOOT CAMP内で日報に書いたら、メンターさんから「作ってみては」とアド$1が。

「ちょっと難しいかも…」と思いつつも、内心「作ってみたい、MY FIRST GEM」という思いが心の中に溢れてきたので、作ることにしました！

使い方

だいたいREADMEに書いてある通りなんですが、英語なので日本語でも書きます。

インストール

一応Ruby3.0.0以上が対象です。

普通にインストールするか

gem install jp_local_gov

Gemfileを使ってインストールします

# Gemfilegem 'jp_local_gov'

bundle install

必要に応じてrequire します。

require 'jp_local_gov'

id指定の検索（`JpLocalGov.find` ）

$1コード（String）を指定することで、$1の情報を取得することができます。

chiyodaku = JpLocalGov.find("131016")# => #<JpLocalGov::LocalGov:0x00007fe706a8f148 @code="131016", @prefecture_code="13", @prefecture="東京都", @prefecture_kana="トウキョウト", @city="千代田区", @city_kana="チヨダク", @prefecture_capital=false>chiyodaku.code# => "131016"chiyodaku.prefecture_code# => "13"chiyodaku.prefecture# => "東京都"chiyodaku.prefecture_kana# => "トウキョウト"chiyodaku.city# => "千代田区"chiyodaku.city_kana# => "チヨダク"chiyodaku.prefecture_capital# => false

この後のメソッドでも共通ですが、取得できる情報は

$1コード
$1府県コード
$1府県（漢字）
$1府県（カタカナ）
市区町村（漢字）
市区町村（カタカナ）
$1所在地かどうか

です。

ひらがなとか英字とかも追加するのは苦ではないんですが、$1が出している元データは漢字とカタカナだけなのと、あんまり$1が見つからなかったので、一旦出していません。

あと東京都の都庁所在地は一応「東京」って習ったと思うんですが、「新宿」として登録しています。

条件指定での検索（`JpLocalGov.where`）

上記の取得できる情報をキーとして、ハッシュを渡すことで、指定した条件に合致する市区町村の情報が配列で返ってきます。

なお複数の条件を指定した場合はAND検索になります。

misato = JpLocalGov.where(city: "美郷町")# => [#<JpLocalGov::LocalGov:0x00007fb1c594cb08 @code="054348", @prefecture_code="05", @prefecture="秋田県", @prefecture_kana="アキタケン", @city="美郷町", @city_kana="ミサトチョウ", @prefecture_capital=false>, #<JpLocalGov::LocalGov:8 @code="324485", @prefecture_code="32", @prefecture="島根県", @prefecture_kana="シマネケン", @city="美郷町", @city_kana="ミサトチョウ", @prefecture_capital=false>, #<JpLocalGov::LocalGov:0x00007fb1c1a3ce40 @code="454311", @prefecture="宮崎県", @prefecture_kana="ミヤザキケン", @city="美郷町", @city_kana="ミサトチョウ", @prefecture_capital=false>]misato.map { "#{_1.prefecture}:#{_1.city}" }# => ["秋田県:美郷町", "島根県:美郷町", "宮崎県:美郷町"]JpLocalGov.where(prefecture: "東京都", prefecture_capital: true)# => [#<JpLocalGov::LocalGov:0x00007fb1c219e418 @code="131041", @prefecture_code="13", @prefecture="東京都", @prefecture_kana="トウキョウト", @city="新宿区", @city_kana="シンジュクク", @prefecture_capital=true>]JpLocalGov.where(prefecture: "東京")# => nil# Exact match search. You should specified "東京都" instead of "東京".

全件検索（`JpLocalGov.all`）

すべての$1の情報を取得したい場合に使用します。戻り値は配列です。

JpLocalGov.all# =>  [#<JpLocalGov::LocalGov:0x00007fdf3a9c6758 @code="011002", @prefecture_code="01", @prefecture="北海道", @prefecture_kana="ホッカイドウ", @city="札幌市na="サッポロシ", @prefecture_capital=true>, #<JpLocalGov::LocalGov:0x00007fdf3a9c6730 @code="011011",...

Railsだと、collection_select を使用することで、すべての市区町村のコンボボックスを簡単に作ることができます。

ランダムな$1情報の生成（`JpLocalGov::Random`）

ランダムな$1情報から、指定したプロパティを返します。

JpLocalGov::Random.code# => "281077"JpLocalGov::Random.city# => "大島町"JpLocalGov::Random.city_kana# => "チュウオウシ"JpLocalGov::Random.prefecture# => "青森県"JpLocalGov::Random.prefecture_code# => "46"JpLocalGov::Random.prefecture_kana# => "ヒョウゴケン"

一応想定するケースとしては、FactoryBotで$1コードを指定する際に、決めうちではんく探索的なテストデータを作成しておきたいという場合を想定しています。

後述しますが、Railsで使用する場合はDBに保持するカラムはlocal_gov_code だけなので、その他のプロパティのメソッドはあまり使い所がないかもしれません笑

補足として、あくまでプロパティ単位でしかランダムな値を生成しないので、ランダムな$1の$1を作成する場合は、

JpLocalGov.find(JpLocalGov::Random.code)

という具合に呼んでやる必要があります。需要があれば、JpLocalGov::Random.new みたいなのを作るかもです。

Railsでの使用（基本）

このGemをModelクラスにincludeすることで、そのモデル内でlocal_govenment というメソッドが使えるようになります。

jp_local_gov :<地方公共団体コードを保存したカラム名> とすることで、そのカラム（$1コード）から、$1府県名や市区町村の情報を展開することができるようになります。

# app/models/insurance_fee.rb:class InsuranceFee < ActiveRecord::Base  # local_gov_code:String  include JpLocalGov  jp_local_gov :local_gov_codeend

insurance_fee = InsuranceFee.newinsurance_fee.local_gov_code = "131016"insurance_fee.local_government.city# => "千代田区"

なおカラム「$1コード」の作成時、型はStringにする必要があります。

Railsでの使用（バリデーション）（`JpLocalGov.valid_code?` ）

$1コードのチェックのためのメソッドを設けているので、これをカスタムバリデーションに組み込むことで、$1コードのチェックができます。

class InsuranceFee < ApplicationRecord  include JpLocalGov  jp_local_gov :local_gov_code  ## カスタムバリデーションで利用する  validate :valid_code?  def valid_code?    unless JpLocalGov.valid_code?(local_gov_code)      errors.add(:local_gov_code, "is not valid code")    end  endend

実施しているチェックは

コードが文字列かどうか
コードが正しい長さか（6文字）
チェックディジットを満たしているか
正しい$1府県コードを持っているか

です。

チェックディジットについては、$1コードの仕様に記載があります。

f:id:ikmbear:20220118162309p:plain

11 検査数字

$1における検査数字は、電算処理にあたって、不正なコードが使われないよう第6桁目をチェック用としたもので、次の方式により算出した数字とする。(方式)第1桁から第5桁までの数字に、それぞれ6.5.4.3.2を乗じて算出した積の和を求め、その和を11で除し、商と剰余(以下「余り数字」という。)を求めて、11と余り数字との差の下1桁の数字を検査数字とする。ただし、積の和が11より小なるときは、検査数字は、11から積の和を控除した数字とする。

出典：https://www.soumu.go.jp/main_content/000137948.pdf🔗

実装としてはこんな感じです。ボリューム的にもプログラミングのちょうどいい問題だと感じていて、結構好きな仕様です。

CHECK_DIGITS_INDEX = 5CHECK_BASE = 11sub_total = code.chars                .take(CHECK_DIGITS_INDEX)                .map.with_index { |digit, index| digit.to_i * (CHECK_DIGITS_INDEX - index + 1) }                .sumcandidate = (CHECK_BASE - sub_total % CHECK_BASE) % 10check_digits = sub_total > CHECK_BASE ? candidate : CHECK_BASE - sub_totalcode[CHECK_DIGITS_INDEX] == check_digits.to_s

なお最初はチェックディジットだけのチェックでいいかなと思っていたんですが、チェックディジットを満たしていても、$1府県コードがイレギュラーになるケースに後から気がつきました。

'481238' # 都道府県は47までなので、こんな市区町村はない# 第1桁から第5桁までの数字に、それぞれ6.5.4.3.2を乗じて算出した積の和を求める80# その和を11で除し、商と剰余(以下「余り数字」という。)を求めて、11と余り数字との差の下1桁の数字を検査数字とする。8　　# 存在しない市区町村だけど、チェックディジットを満たす

なので、$1府県コード（1..47）のチェックも入っています。

仕組み

f:id:ikmbear:20220118161859p:plain

そこまで複雑なGemではないのですが、一応こういう仕組みです。

総務省｜地方行政のデジタル化｜全国地方公共団体コード🔗

情報の元は$1のこのページです。手順的には以下のような感じです。

元データ（PDF）をGem：pdf-readerで読み取る
sqliteにぶん投げる
sqlite内でソートを行う
JSON府県ごとにSELECTしてJSONに出力する
出力されたJSONを使ってJSONコードをパースする

このGemはGitHubコードの情報が命なので、この処理自体をRakeタスクとして登録して、GitHub Actionsで1ヶ月に1回、自動でPRを作成する形式にしています。

今後の展望

まだIssueにも登録していませんが、ここらへんはやりたいなと思っています。

`JpLocalGov.all` で$1の行政区を除外する

「区」って東京のイメージが強いですが、実は各$1府県の$1には区があります。例えば札幌市には$1や東区があります。

市区町村を選択するのに、ここら辺を選択したい場合もあれば、「札幌市」という市区町村の単位だけがあればいいケースもあると思っています（私のアプリもそうです）。

なので、これをオプションで除外できるようにしたいです。一応、$1府県コードに続く3桁の決まりでなんとか除外できそうなので、近いうちに入ると思います。

YARDでドキュメントを書く

@params とかかいてあるあれです。

このGemはRBSを使っているので、それが半分ドキュメントの役割を果たしている感じもしますが、まだまだ普及率も高くないことと、自分自身が書いてみたいので、これも時間ができたらやる予定です。

各RubyバージョンでのテストのCIを実行する

強いGemのCIで走っているあれです。

今はrubyにruby-versionをおいて、それをGitHub Actionsで参照するようにしているのですが、これを各Rubyバージョンで実行できるようにしたいです。

どうやってやるのかわからんですが。

曖昧検索、一つのプロパティに対して複数条件検索、OR検索

今実装しているwhere は完全一致検索かつAND検索で、一つのプロパティに対して一つの条件しか指定できないんですが、ここら辺をもうちょっと柔軟にしたいです。

あんまり使う機会ないんですけど、なんかできたら良さそうな感じするじゃないですか。

変更差分の$1

リリースしてからまだ時間が立ってないので、$1コードの変更は起こっていないんですが、変更が発生した場合になんかいい感じに見せられないかな〜とぼんやり思っています。

終わりに

というわけで、$1コードをパースしてくれるGem「jp_local_gov」をリリースしたというお話でした。

前にもnpmを作ったことはあったのですが、今回はちゃんと実践的に使えるものを作ったので、いろいろと学びも多かったし、楽しかったです😄

（npmの話はこちら）

ikmbear.hatenablog.com🔗

市区町村まで必要になるケースってそんなに多くないかもですが、もしこのGemを作っていただける方がいるなら嬉しいです！バグや要望はIssueにお気軽に登録してください！

github.com🔗

日本の地方公共団体コードをパースするGemをリリースしました

公開日: 2022/1/18

最近のScrapboxの使い方（2021/12）

2021/12/19

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211015/20211015135059.png🔗

f:id:ikmbear:20211015135059p:plain

ikmbear.hatenablog.com🔗

2ヶ月前にこんな記事を書きましたが、微妙に進化している & LT会でScrapboxについてお話ししたので、現状のカスタマイズをScrapboxと合わせてご紹介します。

UserScriptとUserCSS
- UserScript
- UserCSS
UserScript
UserCSS
- ピン留めされたページを別の段として表示する
- セクション用の見出しCSS
運用方法
Scrapbox用クライアント

UserScriptとUserCSS

この記事に記載してあるカスタマイズ内容には、ScrapboxのUserScriptとUserCSSを使っています。

UserScript

JavaScriptを使ってページを動的にカスタマイズできる機能です。

f:id:ikmbear:20211218223348g:plain UserScriptの有効化

有効化：TOP > User settings > Extensions > User Script「Enabled」をオンにする

f:id:ikmbear:20211218223615p:plain

自分のユーザーページ（ユーザー名と同じタイトルのページ）にcode:script.jsという形式でコードを定義することで、そのJavaScriptを有効にすることができます（コード変更直後は、一度トップページに戻って、表示されている「再読み込み」的なボタンをクリックする必要があります）。

scrapbox.io🔗

UserCSS

CSSを使って見た目をカスタマイズできる機能です。

settingsというページを作って、code:style.cssというCSSを書くことで、そのプロジェクトでのみ有効なCSSを定義することができます。

f:id:ikmbear:20211218233446p:plain UserCSSの設定例

scrapbox.io🔗

UserScript

UserScriptでカスタマイズしている機能を紹介します。

テンプレート

f:id:ikmbear:20211218233939g:plain

各種テンプレートをボタンクリックで挿入する$1です。

仕組み

テンプレート機能は次の3つから構成されます。

テンプレートボタンを追加する機能（UserScript）
テンプレートボタンの見た目を編集する機能（UserCSS）
挿入するテンプレート（ただのページ）

テンプレートボタンを追加する機能

f:id:ikmbear:20211218235145p:plain

// UserScriptとしてユーザーページに追加するaddTemplateItemsToPageMenu()  function addTemplateItemsToPageMenu() {    // テンプレートメニューの定義ここから ----------   const __templates = [     { title: '🥞today', url: '/api/code/ikuma-t/template/today.js' },     { title: '🥞tomorrow', url: '/api/code/ikuma-t/template/tomorrow.js' },     { title: '🚀release', url: '/api/code/ikuma-t/template/release.js' }     // メニューを追加する場合は、同じように行を追加する。     // titleにはテンプレートメニューに表示する名前を、urlはそのテンプレートがあるスクリプトのURLを指定する     // `api/code/{自分のユーザー名}/{テンプレートファイルを置いているページ名}/{テンプレート名}.js   ]   // テンプレートメニューの定義ここまで ----------      const __templateMenuTitle = 'Templates'   scrapbox.PageMenu.addMenu({ title: __templateMenuTitle, image: '/assets/img/logo.png', onClick: () => { } })   __templates.forEach((template) => {       scrapbox.PageMenu(__templateMenuTitle).addItem({            title: template.title,           onClick: () => { __loadTemplate(template.url) }})   })      const __loadTemplate = templateUrl => {     if (scrapbox.Page.lines && scrapbox.Page.lines.length == 1) {       const line = document.getElementById('L' + scrapbox.Page.lines[0].id)       const lastChar = line.querySelector('span.char-index:last-of-type')       const textarea = document.getElementById('text-input')       lastChar.dispatchEvent(new MouseEvent('click', {bubbles: true, cancelable: true}))       textarea.dispatchEvent(new KeyboardEvent('keydown', {bubbles: true, cancelable: true, keyCode: 35}))       // テンプレートを読み込む       $('#text-input').load(templateUrl, function (response, status, xhr) {         if (status == "success") {           try {             // 読み込んだテンプレートをテキストエリアにセット             textarea.value = /\.js$/.test(templateUrl) ? eval(response) : response             // テキストエリアのinputイベント             textarea.dispatchEvent(new InputEvent('input', {bubbles: true, cancelable: true}))             console.log("できました")           } catch (ex) {             console.log("だめでした>< \n" + ex)           }         } else {           console.log("だめでした>< \n" + status)         }       })     }   } }

テンプレートボタンの見た目を編集する機能

f:id:ikmbear:20211218234758p:plain

こんな感じにFontAwesomeを使っていい感じのアイコンにします

/* UserCSSとしてSettingsページに追加する */a#Templates.tool-btn:hover { text-decoration: none }a#Templates.tool-btn::before { position: absolute; content: '\f067'; font: 900 21px/46px 'Font Awesome 5 Free' }a#Templates.tool-btn img { opacity: 0 }

挿入するテンプレート

f:id:ikmbear:20211218234852p:plain

これは適当なページを作って、そこにテンプレートをコードブロックとして定義するだけです。
なおJavaScriptで書く必要があります。

ただし、「テンプレートボタンを追加する機能」からアクセスするので、ちゃんとテンプレートごとに別々の名前で定義しておく必要があります。

ページ名についてはなんでも良いのですが、管理がしやすいので「template」というページに設置しています。

以下に自分が作成しているテンプレートのコード例を示します。

日報テンプレート

毎日の日報ページを作成するためのテンプレートです。

// today.js (function() {  const today = new Date()  const year = today.getFullYear()  const month = ("0"+(today.getMonth() + 1)).slice(-2)  const date = ("0"+today.getDate()).slice(-2)  const yesterdayDate = ("0"+(today.getDate()-1)).slice(-2)  const tomorrowDate = ("0"+(today.getDate()+1)).slice(-2)   return `　←[${year}/${month}/${yesterdayDate}]：[${year}/${month}/${tomorrowDate}]→　　[{ 日報] [*** 👍やったこと]  [_]  [*** 🎓学習したこと] [** 【わかったこと】] [** 【わからなかったこと】]  [*** 🥷次にやること]  [*** 🍘感想・余談] 　[{ ライフログ]` })()

私は毎日明日分の日記を作ってから1日を始めるので、明日分のテンプレートも作っています（ほぼほぼ同じです）。

// tomorrow.js (function() {  const today = new Date()  const year = today.getFullYear()  const month = ("0"+(today.getMonth() + 1)).slice(-2)  const date = ("0"+(today.getDate()+1)).slice(-2)  const yesterdayDate = ("0"+(today.getDate())).slice(-2)  const tomorrowDate = ("0"+(today.getDate()+2)).slice(-2)   return `　←[${year}/${month}/${yesterdayDate}]：[${year}/${month}/${tomorrowDate}]→　　[{ 日報] [*** 👍やったこと]  [_]  [*** 🎓学習したこと] [** 【わかったこと】] [** 【わからなかったこと】]  [*** 🥷次にやること]  [*** 🍘感想・余談] 　[{ ライフログ]` })()

じぶんRelease Notesテンプレート

週/1ペースで書いているじぶんRelease Notesのテンプレートです。
最近作ったばかりなので、ちょっと荒削りです。

// release.js  (function() {   const today = new Date()   const year = today.getFullYear()   const month = ("0"+(today.getMonth() + 1)).slice(-2)   const date = ("0"+(today.getDate()+1)).slice(-2)   const thisWeek = Math.floor(date / 7) + 1   const lastWeek = thisWeek - 1   const nextWeek = thisWeek + 1      const birthDayYear = 1995      const age = year - birthDayYear     return ` 前：[じぶん Release Notes（ver 0.${age}.${month}.${lastWeek}）] 次：[じぶん Release Notes（ver 0.${age}.${month}.${nextWeek}）]  本日[${year}/${month}]/${date}、ikuma-t（ver 0.${age}.${month}.${thisWeek}）がリリースされました  [** 今週の日記]  [*** 📆振り返り（KPT）] [** KEEP]  [** PROBLEM]  [** TRY]  [*** 🍳感想] 　`  })()

今日のページに移動するボタン

f:id:ikmbear:20211218235744g:plain

別のページを開いているときに、ふと自分の日報ページにメモを残したくなることがあります。そのためのボタンです。

  const today = new Date()  const year = today.getFullYear()  const month = ("0"+(today.getMonth() + 1)).slice(-2)  const date = ("0"+today.getDate()).slice(-2)  const formatToday = encodeURIComponent(`${year}/${month}/${date}`)  const menuTitle = 'Daily'   scrapbox.PageMenu.addMenu({    title: menuTitle,    image: 'https://twitter.com/favicon.ico',    onClick: () => window.location.href = `https://scrapbox.io/ikuma-t/${formatToday}`  })

こちらも見た目をFontAwesomeにするために、UserCSSを書いています。

 a#Daily.tool-btn:hover { text-decoration: none } a#Daily.tool-btn::before { position: absolute; content: '\f783'; font: 900 21px/46px 'Font Awesome 5 Free' } a#Daily.tool-btn img { opacity: 0 }

$1などを表示する

f:id:ikmbear:20211219000106p:plain

ログを書くための拡張表現をJavaScriptで描画する機能です。どっかから拾ってきたんですけど、どこから拾ったか忘れました。

 const tagIconStyles = {    "!" : "{ content: '\\f06a'; color: #F6AE2D }",   /* ひらめき */   "?" : "{ content: '\\f059'; color: #758E4F }",   /* 疑問、要調査 */   "*" : "{ content: '\\f069'; color: #F26419 }",   /* 重要 */      " " : "{ content: '\\f0c8'; color: #08BDBD }",   /* タスク */   "x" : "{ content: '\\f14a'; color: #2489C5 }",   /* 完了タスク */   ">" : "{ content: '\\f14d'; color: lightgrey }", /* 先送りしたタスク */   "<" : "{ content: '\\f274'; color: lightgrey }", /* 日付を決めたタスク */   "e" : "{ content: '\\f192'; color: #F26419 }",   /* イベント */      "good" : "{ content: '\\f164' }",   "bad" : "{ content: '\\f165' }", };  (function(m){   let charSelectors = [], afterLinkSelectors = [], iconStyle = ""   const linkSelFmt = ".line:not(.cursor-line) a[href='./#']:not(.icon)"   const charStyle = "{display:inline-block;width:0;text-indent:-9999px}"   const afterLinkStyle = "{display:inline-block;min-width:1.15em;padding-left:1px;font: 900 110%/normal 'Font Awesome 5 Free';text-align:center}"   const a = "::after", f = " span"   const enc = ['@$&+=:;", ','@$&+=:;",_']   const encode = tag => Array.from(tag).map(c => {      const i = enc[0].indexOf(c)     return -1 < i && enc[1][i] ? enc[1][i] : encodeURIComponent(c) }).join("");   for (var k in m) {     const href = encode(k)     charSelectors.push(linkSelFmt.replace(/#/, href) + f)     afterLinkSelectors.push(linkSelFmt.replace(/#/, href) + a)     iconStyle += linkSelFmt.replace(/#/, href) + a + m[k]   }   let style = document.createElement('style')   style.appendChild(document.createTextNode(charSelectors.join(",") + charStyle))   style.appendChild(document.createTextNode(afterLinkSelectors.join(",") + afterLinkStyle))   style.appendChild(document.createTextNode(iconStyle))   document.head.appendChild(style) })(tagIconStyles)

UserCSS

UserCSSでカスタマイズしている機能を紹介します

ピン留めされたページを別の段として表示する

f:id:ikmbear:20211219000528p:plain

Scrapboxではページをピン留めすることで、トップページの最上段に貼り付けられます。
このCSSはピンされたページだけ別の段として表示するものです。

 .page-list-item.pin + .page-list-item:not(.pin) {    clear: both; }

セクション用の見出しCSS

f:id:ikmbear:20211219001027p:plain

日報に使っているセクション用の見出しを作るCSSです。[{ 文字 ]とすることで、見た目が変わります。

   .deco-\{, .deco-\} {     font-size: 0.9em;     color: #fff;     background-color: #FB7476;     padding: 0 0.5em 0 0.5em;     margin-bottom: 0.4em;     border-radius: 0.2em;     display: inline-block;     max-width: calc(100% - 100px);     vertical-align: top;   }

運用方法

概要

個別のメモページはそのままページを作っていますが、それ以外のページは以下の4種類です。

日報 & $1（毎日）
じぶんRelease Notes（毎週）
月次ページ（毎月作って、毎日更新）
年間ページ（毎年作って、毎月更新）

日報 & $1

f:id:ikmbear:20211219001408p:plain

毎日作るページです。

基本的に1日のはじめに「今日やったこと」にやることをタスク形式で書き込みます（UserCSSにより[_]と書くことでUserCSSが、[x]とすることで完了のUserCSSが、それぞれ描画できます）。

だいたい前日の「次にやること」をコピペしています。

あとはすべての作業を$1以下に書き込んでいき、1日の終わりにこれを日報の各セクションに振り分けて、FJORD BOOT CAMPに提出します。

ScrapboxはMarkdown形式ではないので、変換が必要ですが、これは後述のsbeというアプリで行っています。

じぶんReleaseNotes（週報）

f:id:ikmbear:20211219002218p:plain

週の振り返りです。毎週金曜日に書いています。金曜日書く理由は働いている時は土日が最も時間がとれたので、土日をスタートにすると週の計画がうまくいきやすかったからです。

内容は単純なKPTと感想です。あまり無理しないように書いています。また今週の日記を貼り付けて見直す時間にもしています。

月次ページ

f:id:ikmbear:20211219002548p:plain

月の日記をまとめたページです。今月の目標と達成確認も簡単に書いています。

11月の途中からですが、日付の横にはその日の気分の絵文字とタイトルを載せています。（これはKPTで提案されたものです）

ここの部分もテンプレート作れるんですが、1ヶ月に一回しかやらないのと、ブラウザのコンソールですぐに作れてしまうので、毎回for文を書いてリンクを作成しています。

Scrapbox用クライアント

ブラウザでも見られるのですが、sbe: An unofficial Scrapbox desktop app🔗というScrapbox用のクライアントを使っています。

タブが使える
見出し（[* ]など）を⌘ + 1（数字）で挿入できる
右クリックメニューから、Markdownとしてコピーできる

という理由で使っています。他にも色々できるのですが、今のところちゃんと使っているのは上記3つです。

以上、最近のScrapboxの使い方（2021/12）でした〜！何かご質問があればTwitterまたはコメントでお願いたします！

最近のScrapboxの使い方（2021/12）

公開日: 2021/12/19

⚡️初めてのLT会 Vol.10で登壇しました！！

2021/12/19

に公開

IMAGE: https://cdn-ak.f.st-hatena.com/images/fotolife/i/ikmbear/20211218/20211218205648.png🔗

f:id:ikmbear:20211218205648p:plain

⚡️初めてのLT会 Vol.10に参加しました！

昨日FJORD BOOT CAMP🔗で開催された、ライトニング$1初心者のための発表会、「⚡️初めてのLT会 Vol.10」に参加しました！

今回のテーマは「一年間で得た学びと気づき」ということで、私は「作業するときにログを書いていくと、進捗が捗るよ〜」という話をさせていただきました。

この記事では、主に発表した内容の補足と今回のスライド作成で使ったツールなどを説明したいと思います。

⚡️初めてのLT会 Vol.10に参加しました！
参加の経緯
テーマ：ログ駆動開発
自分の作業の進め方（内容補足）
資料の作成方法（Figma）
練習のために使ったツール：CleanShot X
感想

参加の経緯

初めてのLT会自体は、以前にも登壇者として参加したことがありました。

その時の記事はこちら↓

ikmbear.hatenablog.com🔗

前回登壇した時から1年以上経っていたので「そろそろ登壇しておかなければ」と思い、今回手を上げさせていただきました。主催者のparu🔗さん、ありがとうございます！

テーマ：ログ駆動開発

「ログ駆動開発」ってちょっと言葉としては大袈裟ですね笑。ビジネス本として出したら叩かれそうですが、LTという短い尺だったので、コンパクトにタイトルつけさせていただきました。

もともとは「寄り道レトロスペクティブ」というタイトルで、今年はRailsとかGemのソースにいろいろと寄り道してきた話をしようと思ったのですが、ボリュームが大きすぎたので、その話の中で「どうやって難しい内容に対しても安定して進捗を出していくか」というセクションだけ切り出した内容が今回の話になります。

話している内容的には、以下の記事と多少オーバーラップするところがあるので、気になる方はこちらも読んでいただければ

ikmbear.hatenablog.com🔗

ここからツールの話多めです

自分の作業の進め方（内容補足）

LT会での質問で

どこにログを書いているか
どんな内容を書いているかみてみたい

という内容がありました。LT会中も話した部分はありますが、このブログで一連の作業ルーティンを補足として説明させてもらればと思います。

どこにログを書いているか

ログはすべてScrapboxに書いています。やり方としては1日ごとにページを作成して、その中に書いていくようなイメージです。

ikmbear.hatenablog.com🔗

この記事で書いた内容と変わっていないのですが、次のように日報作成ボタンをJavaScriptでカスタムしているので、それを使って今日のページを作成します。

f:id:ikmbear:20211218192942g:plain

←[2021/12/17]：[2021/12/19]→[{ 日報][*** 👍やったこと] [_][*** 🎓学習したこと][** 【わかったこと】][** 【わからなかったこと】][*** 🥷次にやること][*** 🍘感想・余談][{ ライフログ]

CSSや「日報」の見た目はCSSで拡張してわかりやすいように表示しています。（長くなるのでコードは割愛します。どっか別の記事で書くと思います）。

「日報」のセクションは、そのままFJORD BOOT CAMPで提出するための日報テンプレートになっています。

で、「$1」のセクションが今回のLT会でお話ししたログを書く場所です。ここにログを記載していきます。

どういう風にログを書いているか（ルール）

ルールはあまりありませんが、

日付と時刻を入力する
内容が後から参照できそうなら別のページに切り出す
あとでページになりそうな内容は、とりあえずリンクにしておく

という感じでやっています。

日付と時刻の入力

f:id:ikmbear:20211218193735g:plain

Scrapboxでは⌃ + Tで日付を入力することができます。3つのフォーマットがあるのですが、3回押した際に出てくる時刻入りのフォーマットを使って、ログの入力を開始します。

時刻を入力するタイミングは厳密には決めていませんが、時間が経っていたり、内容が変わるときには大体日付を入力し直すようにしています。

別のページへの切り出し

f:id:ikmbear:20211218194033g:plain

ログを書いている中で、「これまた見返しそうだな」と思ったり、独立した内容になっていたら、その部分を選択して「New Page」を選択することで別ページに切り出しています。

こうすることで後から参照しやすくなります。

とりあえずリンクにしておく

f:id:ikmbear:20211218201827p:plain

ログを書いていると、「この単語後からまとめたいけど、今は時間ないな」「こういう概念でまとめておいたら、自分の考えがまとまりそう」みたいな要素に出会うことが多々あります。

そういう時は文中で、積極的にリンク（[リンクにしたい単語]）を利用していきます。たとえその時点でメモを作らなくても、あとでメモを見返したときに「あ、ここ追記しておこう」という感じで、過去のログから知識が進化する余地を残せます。

タグの機能も使えますが、基本的にはコンテキストの中で自然に残せる内容はリンクとして雑に定義する方針を取っています（こうしておくと自分のメモ見返すの楽しいんですよ）。

どういう風にログを書いているか（実例）

Scrapboxの中に個人的な内容も書いているので、ある時からScrapboxをprivateにしてしまいました。なので抜粋してお届けします。

気持ちの整理

f:id:ikmbear:20211218194831p:plain

本来であればタスクを整理→作業開始、くらいの感じだと思うんですが、やる気が出なかったようなのでタスク整理する前に気持ちを整理しているメモです。

自分で自分を鼓舞していること、今自分の身に起きていることをとにかく書き出していることがポイントです。

f:id:ikmbear:20211218195344p:plain

レビューしてもらった内容があまりいいものではなくて、気持ちが落ち込んでしまった時のログです。なんだかモヤモヤしてしまって、「明日作業するのだるいな〜」と思っていたので、その日のうちに頭の中にあることをとにかく書き出しました（この後めちゃくちゃ寝て、翌日朝から快調に作業ができました）。

「悔しい！劣等感だ！いつだって上がり調子でいたい」「でもこの劣等感はずっと味わっていなかった感情だ！！！うれしくもあるぞ」

見返すと恥ずかしいですが、当時の自分はこうやって吐き出せたことで、悩んでいた時間は5分くらいだった模様です。

普通のログ

f:id:ikmbear:20211218200454p:plain

普通のログは結構やった作業を全部書いていることが多いです。

一番最後に「気になることを書き出してみよう」と書いていますが、このパターンは結構使っていて、実装中もできるだけ頭の中は空っぽにして、今やっていることだけにフォーカスするのに役立っています。

だいたいこのパターンの後に「よしじゃあひとつずつ見ていこうか」「全然わからんな」「本当？今自分が知っていることは何？」みたいな常套句が続きます。

f:id:ikmbear:20211218201241p:plain

これはリファクタされたメモの例で、ログを振り返ると全然書いていないように見えるんですが、例えば「$1・$1・住民税の計算方法」は次のように別のページとして成立した内容になっています。

f:id:ikmbear:20211218201342p:plain

これは技術全然関係ないですが、例えば「PostgreSQLでエラーになった」とか「Railsで例外発生」みたいな事象にあったときには、とことんログを書きながら調べていって、後から別ページに切り出すと、検索性も高くなってとても良きです。

その他のScrapboxの使い方（Scrapbox用のクライアント、各種Scrapbox）については別の記事で紹介したいと思います（長いんで）。

資料の作成方法（Figma）

発表中、資料内のイラスト等にも質問をいただきましたのでここに書いていければと思います。

資料はFigma

今回の資料はFigmaで作成しました。結局Keynote使ったの前回の一回だけだった笑

Figmaを使う理由は

色やフォントをストックしておける
$1を使える
スライドを一覧しやすい

という理由です。

今回のテーマと色選定用ツール

今回は「ログ」についてのお話でした。ログの語源って「ログブック」つまりは「航海日誌」なんですよね。なので、スライドのテーマになっているのは船です。

季節的には冬だったので、冬の夜の暗い海とそこに灯る赤い船のライトをイメージしたカラーにしたらいいかな〜と思っていました。

以前ブログで紹介したPalettableも利用しているのですが、今回はAIで色を提案してくれるHueMintというサービスを使って配色のベースを選択しました（結構ライト目な内容だと最近よくこのサービス使っています）。

huemint.com🔗

ここでベースの黒と文字のグレーを決めて、あとは感覚で合いそうな色をパレットとして作成し、スライドを作成しました。

画像の引用元

漫画風デザイン

f:id:ikmbear:20211218203127p:plain

この画像はどこから？という質問があったのですが、これはOpen Peepsという素材を使っています。

pablostanley.gumroad.com🔗

f:id:ikmbear:20211218203250p:plain

素材の中にこういう漫画っぽいイラストがあったので、コマ割りと中に出てくるキャFigmaターをFigmaで編集しました。

それだけでもよかったんですが、漫画といえば集中線とか$1、$1があった方がいいでしょ、ということでマンガパーツSTOCKというサイトから素材を拾ってきて合成し、今回のスライドの完成です。

mangasozai.com🔗

正直今回のスライドで一番時間がかかった部分でした笑

表紙のイラスト

f:id:ikmbear:20211218203539p:plain

表紙にはログ→航海日誌→船の連想から、船の画像をのせています。これはLoose Drawingというサイトから拾ってきたものです。何かイラストが必要な時は、ソコストかLoose Drawingで拾ってくることが多いです。

loosedrawing.com🔗

アニメの画像

f:id:ikmbear:20211218203749p:plain

これは私が持っているSHIROBAKOのBluray-Diskをスクショしただけです。

🔗

SHIROBAKO Blu-ray BOX 1 スタンダードエディション (3枚組)🔗

Amazon🔗

絵文字っぽいの

f:id:ikmbear:20211218203909p:plain

FigmaではFontAwesomeを利用することができるので、図解にFigmaを使いたい時はFontAwesomeを使っています。

練習のために使ったツール：CleanShot X

今回はFigmaでスライドをつくったのですが、そうすると録画機能がないために練習をどうしようか迷いました（録音するので）。

で、最近購入したCleanShot Xは$1だけではなく、GIFや動画も撮影できることがわかったので、今回はこれを使って録画練習をしました。

cleanshot.com🔗

f:id:ikmbear:20211218204350p:plain

しかも録画するときにワイプで自分の画像もうつせることに気がついたので、もっぱらこのスタイルで録画をしての練習でした。

ここらへんも長くなるので、CleanShot Xについては別記事で書きます（と思います）。

感想

登壇をやるのはそれなりに大変だけど、その分自分の考えをいろんな人に知ってもらえて、やってよかったな〜と改めて思いました！

今回はFJORD BOOT CAMP内でしたが、来年は今作っているGemの内容で外部のLT会にも登壇しにいきたいと思っています！

ではでは〜！

⚡️初めてのLT会 Vol.10で登壇しました！！

公開日: 2021/12/19