1.この記事で達成したいこと 以下 4 点の内容を書き留め、次年度の履修登録の参考にしたい 単位取得状況 授業を受講してから自分に起きた変化 今年度の履修戦略と次年度に向けて 授業のひとこと感想 2.前提 2021 年 4 月に大学 2 年生に編入学し、まもなく 2 年目を終えようとしている。 今年度も昨年度同様、コロナ情勢を踏まえて　リモート環境での受講 となっている。 次年度の募集要項によると、この体制が続く模様だが、前例のないことなのでいつまで続くのかは定かではない cf. 2023 年度 理工学部情報科学科 通信教育課程 募集要項 | 帝京大学 他は昨年度と同じなので割愛 cf. 帝京大学理工学部（通信教育課程）の社会人大学生 1 年目をふりかえる ｜ gkzz.dev 3.単位取得状況 サマリー 総取得単位数は80 内訳 今年度取得単位数は 18 (= 2 単位/授業 * 9 つの授業) 落とした単位 (落単) は 0 、見送り単位数は 8 (= 2 単位/授業 * 4 つの授業) 昨年度取得単位数は 30 編入時の認定単位数は 32 科目別(受講した時期) 単位取得確定 情報科学演習 1(1Q) 情報科学演習 2(2Q) 電磁気学 1(3Q) 電気回路 1(3Q) 電磁気学 2(4Q) 電気回路 2(4Q) 論理数学(秋期のスクーリング) 数理統計学(2Q は不合格、4Q で合格) 応用数学(4Q) 落単は無し(試験未受験) 見送り オペレーティングシステム(1Q or 3Q) コンピュータアーキテクチャ(1Q or 3Q) 情報技術者演習(2Q or 4Q) オートマトンと計算理論(2Q or 4Q) 4.授業を受講してから自分に起きた変化 「コンピュータ・サイエンス」の学部を出ているという隣の青い芝生に魅せられて、自らも足を突っ込んでまもなく 2 年。ほんとうに過酷だった。 人生において重要な岐路に立たされたとき、たいへんそうな道 を選ぶようにしてきたが、今回はいちばんしんどかったかもしれない。 それでも粘って粘って、理転したことが強みとなるところに軸足を置くべきでは？ という考えを持つにいたった。 腐らず、歩みだけは止めず、次年度もがんばりたい。 また、昨年同様だが、少なくとも受講する前は全く興味を持っていなかった学問領域に対して、「単位を取る」という目的の下、時間を区切って踏み込むようになった という感覚も。「あ！それ、授業で習ったやつだ！」という進 ◯ ゼミ現象は、今年度は電磁気学などあまり実務に関連性の薄い授業もとっていたので昨年度ほど感じることはなかった。ただし、数理統計学など何かと使えそうな授業もあったのでたのしみ。 cf. 4.授業を受講してから自分に起きた変化 | 帝京大学理工学部(通信教育課程)の社会人大学生 1 年目をふりかえる | gkzz.dev 5.今年度の履修戦略と次年度に向けて こちらも昨年度と被るところが多い。 ...

1.はじめに 2023 年 2 月中旬にロードバイクで時坂峠の一本松まで行ってきた。 実は、昨年夏にいちどチャレンジしているのだけれども、体力不足と道が分からず、一本松の少し手前の見晴らしのいい景色で引き返してしまい、一本松からの景色を拝むことができなかった。 先週後半に関東では大雪に見舞われたこともあり、路面凍結を心配していたが、スケジュールと天候どちらも恵まれたという絶好の機会がなく、今回意を決して再チャレンジすることにした。 2. どうだったか？ 無事、一本松を拝むことができた。 道路のコンディションも時坂峠を迎えるまでは雪もなく、クルマや自転車もそんなに多くなく快適。時坂峠に入ってからは道路脇に雪が残っていたが、自転車やクルマが問題なく通れるぐらい溶けていた。 2-1. 天候もよかった 天候にはほんとうに恵まれ、自転車に乗っている間は街中では暑くて一番上に着ていた上着を脱ぐほど。林道に入ってからは上着を着るとちょうどよく、日差しが心地よかった。 雨は終日見舞われることがなかった。(当日の檜原村の天気予報は晴れ、最高気温 12°、最低気温-1° だった記憶。) Instagram や Twitter などでここ最近の「時坂峠」のキーワードを含む投稿の写真では、雪が残っている様子が見受けられた。それだけに今回無事に帰路に就くことができ、かつ一本松からの景色も堪能出来て最高だった。 2-2. 感想 景色を言い表そうと思えば「一本松の凛とした立ち振る舞い」、「木々が青々と茂っている」など思いつくが、陳腐に感じてしまう。言葉では形容しがたいものがあった。写真はたくさん撮ったが、それ以上にそのパノラマを目に焼きつけようと長居してしまった。山登りの際には初回に続き、今回も足をつってしまったが、ストレッチしながら粘って一本松を目指した。一本松の姿とそこに広がるパノラマを目にしたら、全身の疲労は吹き飛んだ。ほんとうに来てよかった。いいところだった。 そういうわけなので、今回の道順をかんたんに残しておき、再訪する際の助けとしたい。 3.大まかな道順を写真とともに 目標地点を時坂峠の一本松とし、以下のルートで向かった。 3-1. スタート地点（自宅）(朝早め) 3-2. 五日市駅を正面に左折 3-3. たちばなやさんの駐車場を正面に右折 ここから少し登り気味 少し進むと整備された林道に入っていく 3-4. ちとせ屋さん正面左手の登り道から時坂峠へ入る 3-5. 林道の様子 いくつか、工事中のところがあるも、問題なく通行できた 3-6. 見晴らしのいい景色 前回はこの近辺で体力と道順が分からなくなり撤退 これまで通ってきたところも写真には映っていないだけで雪が残っていたが、このあたりは特に雪が残っていた 景色がよすぎるので前のめりになって転落しないように要注意 ...

1. この記事を書こうと思った背景 パッケージのバージョン管理をするとなったときに真っ先に思い浮かぶツールは Renovate だが、なんと .tool-versions のマネージャーが提供されていなかった。 Managers - Renovate Docs で挙げられている dockerfile などはマネージャーが提供されており、たとえば、Dockerfile の場合、デフォルトで以下の書式の Dockerfile に書かれたコンテナイメージのバージョン管理が major を除いてできる。1 (^|/|.)Dockerfile$ (^|/)Dockerfile[^/]*$ さて、マネージャーが提供されていない .tool-versions に書かれた言語やツールのバージョン管理をどうすればよいだろうか？ 結論から言うと、Regex Manager で .tool-versions から更新管理したいものを指定（キャプチャ）すればよかった。 この記事では、具体的にどうやったか？その設定をするためにどう調べたか？書いていきたい。 2. 前提 2-1. 2022/08/01 時点でのワークアラウンドな方法であること 以下の issue で議論されているように、以前から .tool-versions をサポートしてほしいという声はあがっている。そのため、この記事で書かれていることは、あくまでも 2022/08/01 時点でのワークアラウンドな方法であることとしたい。 Upgrade versions in .tool-versions #4051 2-2. .tool-versions で管理しているもの .tool-versions で管理しているものは、Terraform と Node.js $ cat .tool-versions terraform 1.0.0 nodejs 16.15.0 3. 環境情報 Renovate の実行環境は GitHub App 4. renovate.json5 の設定内容抜粋 regexManagers で .tool-versions に書かれた Terraform や Node.js の現バージョンをキャプチャする。 ...

1.この記事を書こうと思った背景 ぼくはリモートワークで仕事をすることがほとんどだ。リモートワーク下において仕事でのコミュニケーションの大半は テキストベース だが、文章で自分の考えを伝える ことのむずかしさを感じることが多々あった。そうした背景がありつつ、以前読んで読みやすいと感じた『プログラマの数学第2版』や数学ガールシリーズの著者が 『数学文章作法 基礎編 （ちくま学芸文庫）』(以下、本書)を出版しているということで手に取った。本書から学んだことを、ここに書き留めておく。 2.目次 第1章　読者 第2章　基本 第3章　順序と階層 第4章　数式と命題 第5章　例 第6章　問いと答え 第7章　目次と索引 第8章　たったひとつの伝えたいこと 3.本書を通しての学び よい文章を書くことはむずかしいと改めて感じる一方で、じゃあ、どうすればいいか？そのヒントを得ることが出来た。そのヒントを章ごとに挙げていく。 「第1章　読者」より 読みやすい文章を書く 著者は読みやすい文章を書く原則とは、読者のことを考える ことだという たしかに文章を読もうと手にとってもらわなければどんなにいい文章でも意味がない では、読者のことを考える とは何について考えればよいのか？というと、著者は以下の3点を挙げている 読者の知識 読者の意欲 読者の目的 書こうとしている文章は読者の知識レベルに配慮して書かれているか。文章を読み進めようという意欲を掻き立てるものか。読むことで自分の目的は満たされると思ってもらえるか。どれも抜け落ちていた視点だったので、本書を読み進めようという強いモチベーションに駆られた。（しばらく読み進めて、なるほど。これが読みやすい文章かとなった。） また、本書では述べられていなかったが、会社やコミュニティなど書き手と読み手が共通のコンテキストを有する場合には、過去に積み上げられてきたドキュメントから文章の書き方や、そこで使われているローカルルールを押さえておくと、読者にとって読みやすい文章を書く助けとなるだろうとも感じた。 「第2章　基本」より 文は短く これは、何を主張している文か と自問自答 逆説ではない「が」を使い、冗長的になっていないか？ 「ちなみに」と、本筋からはずれているとはいえ、理解の助けとなる話題を提示しているか？ 「第3章　順序と階層」より 書き直しの重要性 書き直しをすることを想定して書き始めるべき 接続詞は使わず、箇条書きで書くことはせずとも、キーフレーズを書き並べるところから始めるだけでもいいかもしれない 「第4章　数式と命題」より あいまいさをなくす ひとつの文章ではひとつのことを伝える 「第5章　例」より 例のファーストチョイスは、典型的なもの その次に極端な例や、あてはまらない例、一般的な例などが続く 例を挙げる際にも、読者の知識レベルやバッググラウンドに配慮すること OSS やクラウドベンダーのドキュメントでよく出てくる Getting Started は典型的な例にあてはまるのだろう。 4.なぜ、よい文章を書くことはむずかしいのか よい文章を書くことはどうしてむずかしいのか。本書を読みながらこの理由について考えていた。 ひとつ挙げるとすれば、やはり書き手と読み手の知識レベルやバッググラウンドにギャップがあることではないだろうか。 だからこそ、読者のことを考える 、つまり、読み手の知識、意欲、目的に関心を持つこと がよい文章を書くうえで、もっともだいじなのではないか。よい文章を書くということは一朝一夕にできるものではないけれどコツコツと続けてモノにしたい。

1.この記事を書こうと思った背景 Terraform の description に複数行書きたいとなったので調べた。また、p.s. に description について分からなかったことも書き留めておく。 2.やりかた Heredoc Strings | Strings and Templates - Configuration Language | Terraform by HashiCorp を読むと、ヒアドキュメント を使うとよさそうだ。 variable の description に使ってみる。 variable "instance_types" { description = <<-EOT 検証用なのでできるだけお金をかけないようにしている。 大きいサイズは、t3.xlarge などがある。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#AvailableInstanceTypes EOT default = ["t2.small", "t3.small", "t2.medium"] #default = ["t3.xlarge", "t3.2xlarge"] } 3.小ネタ)EOT としているワケ Terraform のドキュメントのサンプルコードにおいて、EOT としているのは、end of text の意味を込めているからだという。 In the above example, EOT is the identifier selected. Any identifier is allowed, but conventionally this identifier is in all-uppercase and begins with EO, meaning “end of”. EOT in this case stands for “end of text”. ...