ねこものがたり

プログラミング学習の記録

プログラミングの勉強に学習理論を当てはめて自分を鼓舞してみる

プログラミングを始めて1年ちょっと経ちました。

最初はうまくいかないことも含めてプログラミングを学ぶことそのものが感動や楽しさで満ちていた気がします。(チュートリアル1周目は重かったけどw)

ところが

💀💀💀💀最近辛い💀💀💀💀

なんだかモヤモヤっとしたものが晴れない。 どうしたらスカッとした気持ちになれるだろう。

ちょっとだけ勉強お休みしてみようかな?とも考えましたが、その前に、「あ、そうだ」と思い、学習理論を引っ張り出してみることにしました。

学習理論を学ぶということ

私は学習理論を学ぶのが好きです。

理論、特に学習に関することは時に机上の空論と言われることもありますが、私は基本的には理論を知ることは「自分を知ること」だと思っています。自分のなにかに理論を照らし合わせると"名前"がわかって、理屈もわかって、「自分は〇〇なんだな」と。

"名前がつく"というのは心理的に安心感があると思っているのですが、そういう安心感が今の私に足りないかもしれない。
不安とか焦りとか辛いという気持ちを漠然と抱えている自分に対してやはり漠然と「気合が足りない」「自分に甘い」「もっとやらなくちゃ」と思うだけだと今はちょっとしんどいなという感じがしてます。

そんなわけで安心を求めて考えてみることにします。


私が学習理論を好きになったきっかけは「レミニセンス」について知ったときです。レミニセンスというのは学習直後よりも一定時間後のほうが達成度が高くなる現象のことです。ものを覚えることに関して使われることが多いけれど実技的なことにも当てはまります。

(参考:わかりやすく書いてあります)

english.suntomi.com

子供の頃、音楽をやっていた私は”「もう手が動かない、痛い」って言うくらい練習しても全然できない時に、ふてくされながら寝たりして一旦間を開けたら、もがいていたときに入っていた力がぬけてふと成功する、その後はずっとできる”という経験が度々ありました。

幼い頃は経験知として「自分はそういうふうにやらないとできない」と思っていて、だんだん初見でもさらさら演奏できるタイプの人が羨ましい気持ちも芽生えて「あの人はさらっとできるのになあ」と比べて落ち込んだりしていました。(昔からやたらできる人と比べてたんだなあ・・・)

学習理論は大学に入ってから学んだのだけれど、初めてレミニセンスを知った時に私のあの身につけ方に名前があるんだなと知れて、「私はあれでいいんだな」って思って心が軽くなったのを覚えています。

今の自分と学習理論

一般的な学習曲線

先程挙げたレミニセンスは単発でみる現象といえますが、長期的にどう学習していくかでいうとなんといっても基本は学習曲線です。 見やすくて良いグラフないかなーと調べていたら、素晴らしいページが公文にありました。さすが。

学習の成果は、こうして上がる: 公文式 ステップアップ・アドバイス | 公文教育研究会

この中にあるこのグラフが学習曲線。 どう見るかはこのページに書いてあるとおりです。公文さんありがとう。わかりやすいよ。 f:id:neko314:20180809122608p:plain

準備期間→伸びる→行き詰まる(プラトー。いわゆるスランプ)→さらに伸びる

公文によるとプロレベルになるにはこれを3回繰り返すって書いてあります。

3回。3回かあ。 もっというとこの3回と言われている中でさらに小刻みに成長と停滞を繰り返しているはずなのでもしかしたら10回とか100回とか・・・ともっと言ってもいいかも知れないです。

原因帰属理論

成功・失敗は何のせい?(原因帰属とモチベーション) - ビジネスのための一般教養

帰属理論・原因帰属 : 心理学用語集

これも有名な理論ですが、改めて自分で見てみると、しんどい時にはたいていこれの「ハマりがちな典型」をすすんでる自分に気づくので、自分にとって大事な理論です。

f:id:neko314:20180809201059p:plain

物事がうまくいかない時(上手くいったときもだけれど)、何が原因と考えるかというものですが、わたしはだいたい、意識していないと”「1) 本人の先天的・潜在的能力」が原因だと考える”を繰り返してしまいます。

こういう理論の好きなところの1つが、わたしみたいな思考を「そんなふうに考えるなんておかしいよ」言わなくて「そう考えてしまう人もいるよね、したくなくてもついそう考えちゃうんだよね。だけどその癖を直せば、自信が持てるんだよ」と教えてくれるところです。

今の自分はどうだろう

私は今は停滞期だと思います。

まじで本当に辛い。一向にできるようにならないので辛い。周りが輝いて見える。そして自分は沼か日陰にいる気がする。自分が嫌いになる毎日。

「才能がない」
「向いていない」
「もうこれ以上できない」
「私には無理だ」

そういう弱音や諦めの言葉が、泉のように湧いて出てくる毎日です。

だけど❗️

だけど今は私は停滞期なんだと、心では思えなくても頭で言い聞かせています。 。

だからこのグラフをみてみて、こう考えます。

「私は今停滞期のどこかにいて、今は伸びることより繰り返すことを大事にすればいい。繰り返しているうちにこの停滞期を超えてもっと伸びるんだ!」

それから、「才能がない」とか「向いてない」とかいって自分を卑下してしまう思考は本当にやりがちで、一番自分でしんどい。

だから意識してみよう。

"「本人の努力」が原因"という観点で「何を変えれば、何をやめれば、何を増やせば成功するかな」と考てみたら、何がわかるだろう。

”「課題の困難度」が原因”の観点で、「この課題は私には難しい、だけどここまではできる。ここができない。この境目が今の自分の目標点だ」と分析してみたら何が見えるだろう。

「こう考えて見つけたことを全部すぐに完ぺきにできなくても、自分を責めないでいよう。今はまず続けることを優先して、しんどさから抜けたらまたやってみようかな。」

感情に流されやすいから、客観的になる時間が必要

私は、時々人に驚かれるぐらいのレベルで、感情が動きやすいです。 ドラマとかすぐ号泣するし、時々ニュースを見るのも内容によっては辛くなってきてだめで、人の気持ちにも入り込みすぎて抜けられなくなったりします。

いいことは「どうしてそんなに私の気持ちがわかるのですか?」と聞かれたりするので、いいように使うと人の役にたてそうなことです。

悪いことは自分自身の感情に流されやすいというか、「あああ悲しい」となると悲しい気持ち100%になって、物事の基準が自分の悲しい気持ちになってしまうような場合があることです。

世の中にはわざわざ意識しなくてもよいマインドを持っている人もたくさんいると思います。

だけど私には、このようになにか理論を持ってきて、客観的になるというのが大事なのかも知れません。

温かい紅茶でも飲みながら深呼吸して少しずつやっていこうと思います。

http://forest17.com/e48/e48ma_tea.jpg

スクラム開発の感想

Fjord Boot Campスクラム開発が始まりました

これまでFjordの共同開発の課題では、各々がメンターの駒形さん、町田さんとやりとりしながら進めていました。私も最初そんな感じでしたが、開発に加わるようになってまだ間もない時にスクラム開発でやっていくことが決まりました! かなり嬉しいです^_^

これまで「アジャイル」とか「スクラム」とか本や会話で読んだり聞いたりして知っている概念に過ぎなかったのですが、実際やってみると「なるほどなー」と思っています。

毎週水曜日がミーティングで、今週水曜日2回目のミーティングがありました。1回目は”どんな感じなんだろう、どきどき”という気持ちで臨んで、終わってもあまり言語化できなかったので、2回分をまとめて振り返ってみたいと思います。

ストーリーの選定

プロダクトオーナーが中心となってどのストーリーを本イテレーションでやるかやらないかを決めます。Fjordの場合はデザイナーの町田さんがオーナーなので、技術的なことだけでなくデザインも含めてトータルで判断しているのかなと、聞いて感じています。

ミーティングに参加することで判断の理由を共有できるのがよいなと感じています。その時時に納得感をもてるというのもありますが、勉強という観点でいうと聞くだけでなく「どうしたらより良くなるか」「どんなニーズを根拠に優先順位をつけるか」を今よりしっかり考えられるようになっていきたいと思えるし、そのためにはどのような視点が必要なのかを体感として学べていると思います。

見積もり

Fjord Boot Campの場合は「どれくらい時間がかかるか」をポイントとして見積もっています。

私自身は見積もりが的確にできず「わからんけどこれくらい?」と推測でやってる感じが否めませんが、ストーリーの決定と同様に「なぜそう見積もったのか」を話し合うことがとても勉強になります。

初めてのミーティングの時にメンターの駒形さんが「プランニングポーカーは話し合うための手段で、しっかり話し合えることが重要」とおっしゃっていたのですが、見積もりを出すことだけではなく、一人だと気づけなかったことを話し合うことで共有できたりするのがよいなと実際参加してみて思っています。

デモ

まだ2回なので見た回数は少ないですしやった回数はもっと少ないですが、他の方のデモが、どういうふうに説明していくとよいのかというのがお手本になっています。 加えて「前こうだったけどこれやってこうなりました」って説明するだけなのに、自分自身に自信がないとめっちゃ緊張するので、場数を踏んでいきたい感じがします。

全体の感想

自分からも発信していくというより聞いたり吸収したりする割合のほうが圧倒的に多いのでやや受け身っぽいかもしれないのですが、スクラムを経験できるのはかなり勉強になっています。

冒頭述べたように読んだり聞いたりしているだけでは理屈はわかってもピンとこなかった点も多いです。

どこかの会社に入ってから「へ〜こういう感じなのか」と思うよりも事前に知れる点と、(仕事とか勉強とか関係なく)経験値が増えるという点、「人から学ぶ」という機会が多くなる点が全然違うかなと思います。

その他

スクラムの感想とは違いますが、リモートでミーティング参加する方もいらっしゃいます。 私自身はこれまでそのようなミーティングをほとんどやったことがなかったのですが、リモートの人がいると話し方をよりわかりやすく意識したほうがいいなと個人課題として思っています。

明瞭さと簡潔さが苦手な私はBootCampの様々な場面でそこに苦戦していて、ミーティングでも意識しないと何が言いたいのか伝わらなかったりわかりにくかったりするかも知れないと懸念してます。

今の所ミーティングに関しては特にそういう指摘を受けたわけではないのですが、自分の中で留意していきたい点です。

MySQLを指定したRailsアプリでrake db:createする前の手順

実践ruby on rails 4 現場のプロから学ぶ本格webプログラミングをやっていて引っかかったのでメモ。

起こったエラー

$ bin/rake db:create

Access denied for user 'root'@'localhost' (using password: YES)

database.ymlの内容

default: &default
adapter: mysql2
encoding: utf8
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
username: root
password: password
socket: /tmp/mysql.sock

手順

1.パスワードを生成してする

2.MySQLにアクセス権限を持つユーザーを追加する

3.database.ymlを変更する

1. パスワードを生成する

$ mysql
mysql> SELECT PASSWORD('mypass');
->
+-------------------------------------------+
| PASSWORD('mypass')                        |
+-------------------------------------------+
| *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
+-------------------------------------------+

7/30追記 この1の操作はパスワードではなくハッシュの生成でした。手順としては1.は不要でした。教えてくださりありがとうございました!

2. MySQLにアクセス権限を持つユーザーを追加する

$ mysql
mysql> CREATE USER 'railsuser'@'localhost' IDENTIFIED BY 'mypass';
->Query OK, 0 rows affected (0.15 sec)

mysql> GRANT ALL PRIVILEGES ON *.* TO 'railsuser'@'localhost';
Query OK, 0 rows affected (0.01 sec)

3.database.ymlを変更する

default: &default
adapter: mysql2
encoding: utf8
pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
username: railsuser    //追加したユーザー
password: mypass   //先程のパスワード
socket: /tmp/mysql.sock

参考

Ruby on RailsでMySQLを使用する際に必要な作業手順

MySQL :: MySQL 5.6 リファレンスマニュアル :: 6.1.2.4 MySQL でのパスワードハッシュ

できるようになりたいことをリストアップしてみた

長期的また理想で言えばたくさんの願望がありますが、とりあえず時系列を絞って「直近でできるようなりたいこと、身につけたいこと」を考えても山のようにあります。

あれもこれもとなって「そういえばこれも気をつけるんだった!」となっちゃうと効率が悪いし身につきづらいと思うので、文字にしてみて1つ1つのことに丁寧に意識をもっていけたらと思っています〜がんばろー!

技術面

目標 思い 手立て
テスト ちゃんとしたテストが書けると実装力もあがりそう、心に余裕も生まれる。 『Everydayrails』をもう一周(7月末までに)、他の本も探そう
Active Record 何もわかってないのですべてがわからない気がしてる まずRailsガイドを理解することから
SQL ちょっと複雑になると、どうなったらどうなるか読み解くのも苦戦 『すらすらと手が動くようになる sql書き方ドリ』がいまのところ自分にはあってる。辞書的にも活用して繰り返す
リファクタ 「もっとよくできる」と気づけないしわからないのでやるのが怖い 簡単な部分だけでもやろうとしてみる

ソフト面

目標 思い 手立て
アウトプット力向上 とにかく苦手、現状は足りてない 自分に向けて発信するつもりで、思いを文字に残す(残そうとすることから!)
質問の仕方 聞き方も聞くタイミングも難しく感じてる 疑問を小分けにしておく。自分の中で考える時間制限を設ける(小分けにして30分を目安にしてみようかな)小分けにすると聞きやすいかも?
日報 活動と所感を切り分けるの未だに苦手でひよっちゃって内容書かなすぎかも 他の人の日報がめちゃくちゃ参考になるので真似してみたりしてる最中。続ける!

目下こんな感じ。(もっともっともっともっとたくさんあるけど!) まずはこれらを今より少しでもできるように、もっと具体的にできること、もっと必要なことがないかなども考えながら過ごして行きたいと思います。

RailsとSQLでわちゃわちゃやってます

自分の課題

DBから前後のデータをとってくる - ねこものがたりの続きをやっていて感じた自分の課題。

  • 複雑なSQLの操作に慣れていない、間違えたり調べたりしてなんとかやってる
  • railsのコードとSQLが自分の中で一致してない(単独でやると操作できるけど相関関係の理解が抜けてる)
  • railsのコードもそもそもそんなに慣れてない。試行錯誤の末長くなったコード。やっとここまできただけで満身創痍。さらにきれいに書くなんてレベルが高い。だがここで倒れたら死ぬと思え(とは言われてない)。

課題に対する策

この課題を踏まえ、またFjordでもらったコードを考えるためのアドバイスをもとに

" .to_sqlで書いたコードがどんなSQLになるか確かめる"

を毎度やることで自分の中に定着させていくことにしました。

考えるときのドキュメント等については以下の3点を参照しています。

Ruby on Rails APIのActrive Record::Query Methodsのところ

Active Record クエリインターフェイス | Rails ガイド

改訂第3版 すらすらと手が動くようになる SQL書き方ドリル:書籍案内|技術評論社

1度分かったと思っても本当に理解してないとすぐに抜けてしまうので、また簡単なところから考えるというのを積み重ねる感じです。(なので今後も継続する)

やってみた

コードがどんなSQLになるか確かめる

前回のコードの一部。

def previous
  Report.order(created_at: :desc).where(user_id: user_id).find_by("created_at < ?", created_at)
end

このメソッドに"同じuser_idとcreate_atをもつレコードが複数あればidが小さいもの"を検索するコードを追加したいと思います。

まず"同じuser_idとcreate_atでidが小さいレコード"で考えました。

最初に書いたコード。

Report.order(created_at: :desc).order(id: :desc).where(user_id: report.user_id).where("created_at = ?", report.created_at).find_by("id < ?", report.id)

SQLに変換する。

$ Report.order(created_at: :desc).order(id: :desc).where(user_id: report.user_id).where("created_at = ?", report.created_at).find_by("id < ?", report.id).to_sql

-> Report Load (0.9ms)  SELECT  "reports".* FROM "reports" WHERE "reports"."user_id" = $1 AND (created_at = '2017-01-02 00:00:00') AND (id < 312758158) ORDER BY "reports"."created_at" DESC, "reports"."id" DESC LIMIT $2  [["user_id", 459775584], ["LIMIT", 1]]

一応できた。(きれいにするのはあと)

コードを書き直す

Report.order(created_at: :desc).where(user_id: user_id).find_by("created_at < ?", created_at)


Report.order(created_at: :desc).order(id: :desc).where(user_id: report.user_id).where("created_at = ?", report.created_at).find_by("id < ?", report.id)

次は、この2つを1つのpreviousメソッドに収めたい。

最初はこう書きました。

def previous

reoport = Report.order(created_at: :desc).where(user_id: user_id).find_by("created_at < ?", created_at)

if report == nil

Report.order(created_at: :desc).order(id: :desc).where(user_id: report.user_id).where("created_at = ?", report.created_at).find_by("id < ?", report.id)

report

この時点で1度レビューを受けましたが、いろいろだめでした。

  • 方針が違う
  • .orderや.whereなどを繰り返していて書き方が良くない
  • Active Recordの使い方が良くない というのがありました。

方針の違いはここではおいておいてActive Recordはメソッドが長い、複雑なものほど処理に時間がかかり重くなるので注意が必要だそうです。

私が書いたコードは
「1回検索する→見つかる」
ならすぐに処理完了となりますが
「1回検索する→nil→もう一度さっきとちょっとだけ違う条件で全部検索する→見つかる(見つからないかも)」
となり下手するとめちゃくちゃ遅くなるので、処理の結果がたとえ同じでも遅い時点で良くない。

なのできれいなコードにするのと同時に、以下のようにしました。

def previous
  Report
    .where("user_id = ? AND created_at = ? AND id < ?", user_id, created_at, id)
    .or(Report.where("user_id = ? AND created_at < ?", user_id, created_at))
    .order("created_at DESC, id DESC")
    .first
 end

いきなりすごい変わった!!!!

SQLに変換するとこう

$ Report.where("user_id = ? AND created_at = ? AND id < ? ", report.user_id, report.created_at, report.id).or(Report.where("user_id = ? AND created_at < ?", report.user_id, report.created_at)).order("created_at DESC, id DESC").first.to_sql


->SELECT  "reports".* FROM "reports" WHERE ((user_id = 459775584 AND created_at = '2017-01-02 00:00:00' AND id < 312758158 ) OR (user_id = 459775584 AND created_at < '2017-01-02 00:00:00')) ORDER BY created_at DESC, id DESC LIMIT $1  [["LIMIT", 1]]

ここに至るまでに、複数条件の書き方がうまくできなかったり、論理演算子と戦ったりして、本当はめちゃくちゃ時間がかかりました。

しかもまだこれで本当にOKかどうかはわからないというw

だけどあーでもないしこーでもないしとやっているうちに少し「自分の中でわかってきたな〜」と思いました。

その他

今回やってみたのはSQL変換ですが、ほかにも「GUIツールを使う」というのも教えてもらいました。

やらなかったのはとりあえず.to_sqlのほうが手っ取り早いと思ったのと、ツールを使ったことがなかったので最初はどう操作しても確実に誰にも迷惑かけないし大丈夫そうなやつで練習したいと思ったからですww

今自分のアプリを作ったりしてるので近々使ってみようと思います!

今後続けていくこと

最初に書いた
* .to_sqlで書いたコードがどんなSQLになるか確かめる

以外に

  • SQLの復習をすること(1度ちゃんとやったけど曖昧):書籍をもう1周中
  • rubyのメソッドrailsのメソッドを理解する:とくにapi.rubyonrails.orgに書いてあるようなこと、とりあえず読もう

この3点が今の自分にすぐできることかな〜と思っています。 他にもあれば教えてほしいです。

今もまだ若干混乱してますがActive RecordまわりのことSQLのことを自分に定着させていきたいです!

トラウマなんかに負けたくないっていう話

過去の仕事での辛い出来事がなかなかにたくさんあります。

特に初めて転職して入った会社(IT関係でも何でもないけど名の知れた会社)がかなりひどくて、日常的にモラハラパワハラ、セクハラ等いろいろありました。

辞めてから数年経ちますが、ふと取り憑かれたように思い出してしんどくなることがあります。

今日、そんな感じでしんどかったです。

調べるとこんな記事がすぐ出てきました。

退職後トラウマに陥らないために - 職場のモラル・ハラスメント対策室職場のモラル・ハラスメント対策室

これを読んで「あ〜そうか、わたしトラウマになってるんだ」って思いました。(気づくのが遅い)

あんな環境に無理して居続けなくて本当に良かったと心から思います。 同時に”ちゃんと区切りをつけてもう引きずりたくない”とも。

ただ、今日思い出した時に”今までと自分変わったかも”って思いました。

思い出すのは過去に言われた言葉がほとんどです。 そしてその言葉がそのとおりに思えて「私は耐えられなかった弱い人間」「他の人のように優秀ではない使えない人間」と、自分を自分で貶めるような思考になりがちでした。

でも今日は「弱かったかもしれないけど少なくとも今は違う」「私はちゃんと頑張っている」「人がどうかなんか関係ない」「私は優秀じゃないかもしれないけどやっていける」って思いました。 (過去言われたことに対して反論する感じ)

少しずつ区切りをつけられてるのかな〜

私は基本的に自分に自信がありません。 足りないから過去のことにとらわれてしまうのだと思います。

もっと自信がほしい。 私にとって今やっていることは自信をつけることにつながって、自信をつけることは過去の自分を助けることにもなるんだと感じました。だからこの記事にしました。

プログラミングは純粋に楽しい。 楽しいからやっているしプログラマーとして就職したいと思ったし、始まりはそうでした。

だけど今日こんな自分自身のためにも絶対にやっていこうという気持ちが強くなりました。

Rails Developers Meetup 2018 Day 3 Extremeに参加しました

7/14に開催されたRails Developers Meetup 2018 Day 3 Extreme に参加してきました。

初めて参加したのですがめちゃくちゃ濃い1日で参加してとても楽しかったです。

準備運営してくださった皆様、本当にありがとうございました!!!

個々の発表についての意見とか考えは周りの経験者さんのものを伺ってみたいなと思っているのですが、個人的には”今の自分だからこう思った”というのを文章にしてみたいと思ったので書いてみます。

最近の自分

  • Fjord Boot Campでがんばっている
  • 自分の作りたいアプリを作るためにデッサンややるやらリストやらばかり唸りながら考えている(遅々として仕様が決められない)
  • 仕事としてプログラミングやることについて具体的な様子をもっと知りたい
  • アジャイル開発!」よく聞く!本も読んだ!しかし体感が足りない!
  • そういえばテストが楽しいぞ?もっと書きたい気がしてきた!
  • アプリケーションの「ユーザー」って使う人?使う人が影響を与える人もユーザーなのかも?とか思い始めてる
  • よいユーザー体験のためのデザインに関心が高まっている
  • 家にばかり要るので人と戯れたい
  • すごい人のすごい話聞いてすごい人とお話して自分もすごい気になりたい

・ 我らが町田さんが登壇するぞ!!!!!

どのセッションも面白そうでどれを聴くか迷ったので、こんな感じの自分が聞きたいというセッションを中心に聞いてみました。

イベント中の様子

2つのトラックに分かれて20分のセッションをどんどん回していくスタイル。 質問はAMAで募っておいて、時間に余裕があればセッション後にQAやっていってました。

f:id:neko314:20180715211918j:plain
町田さんによるRubyKaigiのデザインのお話

スライドをまとめてくださってる記事がありました!

qiita.com

f:id:neko314:20180715220444j:plain
株式会社FiNCさんからのお弁当〜ごちそうさまでした!

参加してみて

全部を通して「考える」っていうのがエンジニアとしてやってくために大きな重要な要素なのかなと思いました。

とはいえ考えるときにそうそう立ち止まってもいられなくて、すぐに答えは出ない状況でもやっていくしかなくて。 あるいは突然方向転換しないといけなくなったりして。 そういうなかでもやっていくためには柔軟性とか臨機応変さとかが必要でっていうのを、発表を聞いていて思いました。自分やっていけるのかちょっと怖い・・・

また「ケースバイケースっていうとあれなんですけど」って何人かの発表者が言っているのを聞いて、結局は個々の問題だとしてもできるだけ「こういうふうにするといい」っていうのを共有していくことで生産性を高めていく努力をしているのがエンジニアの良い文化なのかな〜とも感じました。

懇親会でもいろんな方とお話できて楽しかったです^_^ こうみえて結構小心者なのでぼっちにらなずに済んだのがめちゃくちゃ嬉しかったです!声かけてくださった皆様、話し相手になってくださった皆様ありがとうございました(歓喜!!!)

そういえば、vimはFjordでもやるけど前はイマイチ慣れなくて「んーー」って思っていました。だけどNginxでなんちゃらかんちゃらとかやっているうちに「これは便利だ」と気づいてしまったのですっかり使うようになっていて、発表が楽しかったですww