Posts

※CSSの設定を誤り、ここ数日まともに見れない状態が続いておりました。アクセスしてくださった方は申し訳ありませんでした。hugo serverを実行しlocal hostで確認した際は問題無かったのですが。。。原因も含めて、今後もCSSの設定周りを見直していきたいです。 keyball44について🎱 自作キーボード界では有名なキーボードだと思います。トラックボールを常用している自分としては前々から欲しいと思っていたのですが、しばらく在庫切れが続いており、手に入れることができませんでした。先日、その在庫が復活した旨をTwitterで知り、購入した次第です。 Keyballシリーズの在庫を追加しました！😆 結構数量豊富ですので焦らずご検討いただければと思います🙏 よろしくお願いします！#Keyball44 #Keyball39 #Keyball61 https://t.co/UjwQGQgXyf — 白銀ラボ　ﾖｰｷｰｽ🎱 (@Yowkees) October 6, 2022 ※上のTwitterカードはHugoのShortCode機能を使ってMDに記入しました！ 説明不要かもしれませんが、特徴を簡単にまとめておきます。 左右分離式 40%キーボード（キーの数は44個） トラックボールを搭載（左右どちらの搭載可能）　←圧倒的個性と魅力！ Cherry MX 互換キースイッチ（ホットスワップ対応・手前の5つはchocにも対応） LED搭載可能 キーボードで入力を行いつつ、トラックボールによるマウスの操作をすることができるという、大変優れたデバイスです。 想像してください。自分が、キーボードとマウスの入力を大変シームレス（継ぎ目なく）行っている様を。興奮しますよね？😤 全くの余談ですが、想像することの大切さは『Laundry』から学べます。とても良い邦画ですよ。 キット以外に購入したもの chocキーキャップとchocスイッチ Cherry MX 互換キーキャップ 34mmトラックボール TRRSケーブル（TRSでも可） ProMicro（単体） × 2 キットの内容はこんな感じです。詳しくは製品ページに書いてあります。 keyball44、届いたので早速組み立て頑張ります💪 pic.twitter.com/AKHdmMzgpM — rinyacho (@rinyacho_jp) October 9, 2022 準備したもの 遊舎工房さんの工具セットを参考に準備しました。はんだごてから、ピンセットまで、基本的に全部。 keyball44組み立てに、ほぼほぼ必須ではと私が感じたアイテムとしては、 はんだごて 平らな面があるコテ先 コテ台 はんだ ピンセット（先の細いもの） プラスドライバー マスキングテープ キーキャップ引き抜き工具 ※無くてもなんとかなると思ってたけど実際は無いと厳しいと思われる。製品自体は何でも良いと思います。私はHHKBのキーキャップに付属していたものを使用しました。 以上といったところでしょうか。はんだ付けの熟練度によっても変わってくると思います。逆に、準備が足りなかったのは、フラックスと、はんだこて作業マットです。特に作業マットはダンボールで代用したので、少し触れただけで簡単にズレてしまい、四苦八苦しました。 私がハマったポイント 前提 基本的に、ビルドガイドが下記に詳しく書いてあるので、それに従うことが必須です。私は結構読み込んで、割りと慎重に進めていったと思います。 https://github.com/Yowkees/keyball/blob/main/keyball44/doc/rev1/buildguide_jp.md ダイオードのはんだ付けが細かくて泣く これには少し驚きました。私が経験したことのあるはんだこての細かさではありませんでした。最初は落ち込みましたが、やってみると案外とはんだ付けできましたが、どれくらいはんだを盛ればいいかがうまく掴めませんでした。 画像上に見える点がはんだ付けするダイオード。。。...

ITエンジニア的な情報に浸っていると、「読書会」なるワードを見かける機会があります。他にも「もくもく会」とか、「勉強会」とか、ありますよね。どんな感じなんだろうなぁと興味を持ちつつも、参加の機会はありませんでした。自分に実務経験が無いのもあり、専門的な内容の読書会への参加がはばかられた部分もあります。 ある記事をはてなブックマーク経由で閲覧した時、『人月の神話』読書会、なるものを見つけました。そこから、CONNPASS経由で参加させていただきました。『人月の神話』の存在は知っており、興味があったので、丁度良かったです。人月の神話が技術書の中の分類としては、エッセイ的なもの（特定の言語やそのフレームワークを取り上げた本とは異なる）でしたので、参加もしやすかったです。 ※本イベントを見つけた段階で、CONNPASSで参加者を募集している期限は過ぎていましたが、イベントページの問い合わせ欄から参加したい旨を連絡すると、承諾していただくことができました。感謝感謝。 ※イベント当日までは参加登録できるだろうと勝手にたかをくくっていました。以後は募集期間をしっかり確認したいです。 『人月の神話』については、ご存知の方も多いと思います。そう、バベルの塔が表紙の難しそうな本です。 読書会を概観しつつ、『人月の神話』について章毎に気になった内容をまとめていきたいと思います。 読書会について ※n=1の内容です。当たり前ですが、これが平均値や普通というわけではありません。 参加者数：15名程 時間：4時間程 参加者層：年代性別色々（男性多め）。ITエンジニア的仕事をしている方々が集まった（私を除いて）。 形式：1人ずつ、1ページを音読する。1人が音読中は、他の人はそれを聞く。気になる点があれば都度、共有・議論する。 ※議論・共有は、読み進めている途中でも読み終わった後でも可。読み終わった後の方が多かったかな。 コミュニケーション方法：ZOOM、ビデオカメラの使用は必須では無いが半分くらいの人が共有、自分が話す時や議論する時以外はミュート設定にしている人も多かった 進み具合：64ページ、1～6章 読書会に参加しての所感 人月の神話を既読の人が半分程いたのですが、少し意外でした。読んだこと無い人が主に参加するのかなぁとなんとなく思っていたので。ただ、既読の人がいるからこの内容は飛ばすといったことはありませんでしたので、特段問題無かったと思います。既に読んだ人でも、あまり理解できなかった（理解を深めたい）人、随分前に読んだので内容を復習したい人等、色んな人がおりました。まあ、有名な作品ですし、既読の人が多いのもよくよく考えれば納得です。前の版を読んだけど、新装版は読んだことないという方もいました。 原著は1974年に書かれており、その新装版が1995年に出版され、その英訳が日本で出版されたのが2014年です。この2014年に出版されている本が今回の読書会の対象となっています。文章のほとんどは約50年前に書かれた内容であり、一部の新しい箇所でも約30年前という状態です。「プログラム事務係」「電話の記録を残す仕組み」等、聞き慣れない文や単語も多くありました。そういった、現代と認識の差異が箇所について、ベテランの方が自身の経験や知識で内容を補填してくれるのは、嬉しい誤算でした（プログラムテスト実施方法の違い等）。 主催者の方が仕切ってくれたのも良かったと思います。前述の通り、読書会の経験はありませんが、グループワークの経験は何度かあります。その経験からも、誰か、グループを取りまとめてくれるファシリテーター役がグループワークには必須のように思います（少なくとも気の知れた仲同士で無い場合）。議論が長引いたり、脱線しそうになった時はうまくコントロールして貰えました。ありがたいです。 読書会の後、自由にコミュニケーションを取れる時間が1時間程ありました。残った人は半分くらいだったと思います。詳しい人が残ってくれている場合は、質問のチャンスですね。私も聞いてみたいことがありましたが、お知り合い同士？なのかな、会話の応酬がややハイスピードでしたので、切り出せずに終わってしまいました。私自身、素人として参加している以上は、その他の方の迷惑にならないように努めようと思っていたので、その辺からも難しさがありました。また機会があれば勇気を出していきたいですね。 人月の神話、いくつか気になった点まとめ 最初に当日読み終わった章のタイトルと画像の内容をまとめておきます。 1章「タールの沼」タール沼の壁画 2章「人月の神話」ニューオーリンズのレストラン「アントワーヌ」のメニュー 3章「外科手術チーム」手術の様子 4章「貴族政治、民主政治、そしてシステムデザイン」ノートルダム大聖堂 5章「セカンドシステム症候群」航空交通用の回転する家 6章「命令を伝える」7つのトランペット 2人のプログラマがガレージで作ったプログラムが、大規模開発チームが最大限の努力で作り上げたそれを凌ぐ。それなら、常に小規模で開発するのが正解とならないのはなぜか。 人と時間が交換可能になる（人を導入すればその分時間が短縮される）のは、その作業に意思疎通を取らなくても分担ができる場合だけである（とても単調な作業など）。 システム開発は上記に該当しないので、人と時間は交換不可能である。それどころか、人数が増えるほど、コミュニケーションのコストが増え、人を増やすほど必要な時間が伸びる減少が起こる。 スケジュールが遅れている時、要員を追加する。追加人員には訓練のコストがかかる。訓練するのは開発チームの人であり、その人の開発の手を一時的に止めることになる。また、追加された人自身も、当然すぐに実作業に取りかかれるわけではない。ブルックスの法則が有名。 少数精鋭チームでの開発はコストパフォーマンスが高い。 しかし、少数精鋭チームが非常に大きなシステム開発（5000人年）をする場合、時間がかかりすぎる（10年）。つまり、現実的ではない（冒頭の疑問に対する答え？）。 システムデザインにおいてコンセプトの完全性が最も重要。 簡単かつ直截的（ちょくせつてき）なシステムが最高だ。片方だけでは駄目。 ※直截的の意味がわかりにくいですが、「迷いの無い」くらいに思っています。簡単と被る部分もありそうですが。 以上となります。 次回以降も、日程が合えば参加したいなと思います。

参考にしている書籍やサイトなど Flutter実践入門 スマホで動くアプリを作ろう！ゼロから始めるFlutter実践入門編 ※1~3含めて Flutter 日本語ドキュメント STEP1 開発機の選定。 マウス・キーボードの設定。 Homebrewのインストール。 AndroidStudioのインストール。 Gitのインストール。 ローカル＆リモートリポジトリの設定。 教材の選定。 STEP2 画像と文字を画面に表示するアプリを作成（写経＋アレンジ）。 意義：基本的な使い方を把握する。 assets/を作成して画像をコピーしてくる。ymlを書き換えて画像ファイルを認識させる。 Image()で画像を表示。 Text()で文字を表示。 body: Centor()（全体配置）、Column()（縦配置）、Row()（横配置）でレイアウト。 MainAxisAlignment.で配置パターンを設定。 child: []とchildren: []で入れ子構造の設定。 リポジトリ：flutter_practice_display STEP3 名前と日付を入力することで、生まれてから現在までの日数を計算するアプリを作成（写経＋アレンジ）。 意義：async・awaitの処理に触れる。小技を覚える。画面遷移の手法やその書き方を身につける。 appbar:で画面上端のバー＋テキストを表示。 StringとDateTimeの型で変数生成。 InputDecoration()でテキスト入力欄のデザイン設定。 print()でconsoleに値を出力。デバッグでも有効。 Icon:でアイコンを表示。 Padding()で4方向のレイアウト調整。 SingleChildScrollView()画面内に治まらない時のスクロールに対応。 if文でnull回避。hoge!にてnullで無いことの証明。 TextField()やShowDatePicker()を使用して入力パターンを設定。 onPressed:を使用してタップ動作の検知。 aysncとawaitを使用して動作に時間差があるデータの格納に対応（カレンダーを表示する→日付を選択する）。 新たなclassを作成。 lib/に.dartファイルを追加して、新たな画面を作成。 変数の作成、変数の画面間渡し。 Navigator.push()とMaterialPageRoute(builder: (context) =>)を使用してmain.dartから画面遷移。 リポジトリ：flutter_practice_calc STEP4 本記事の初回作成。 プロフィールを表示して、シェアするアプリを作成中（写経＋アレンジ）。 意義：パッケージの導入方法とその適用の勘所を身につける。例外処理、async・awaitの処理に慣れる。 url_launcherパッケージのインストールと適用。 launchURLでメールアプリの自動起動と適用するテキストを設定。 Future<void>、async、awaitで時間がかかる処理の対応。 if + throwで例外処理。 fontSize:とfontWeight:で、文字の大きさと強さを変更できる。 share_pluspackageを導入して、シェア動作を入れる。 screenshotpackageを導入して、スクリーンショットを取る動作を入れる。 path_providerpackageを導入して、スクリーンショットのデータとのパスを繋ぐ。 backgroundColor:で背景色を指定する。 下記のErrorが発生。SDKの紐づけが出来ていなかった（NoSDK）のが原因っぽい。File→Project Structureで、SDKを設定したところ、解消された。 参考サイト：Android Studioで作成したFlutterプロジェクトがGradleまわりのErrorを… Cannot resolve symbol 'Properties' Cannot resolve symbol 'Properties' 書くコードの量が多くなってきており、手間取った。また入れ子構造への理解が薄い、VScodeもまだ使い慣れているとは言い難いので、時間を要してしまう。 リポジトリ：flutter_practice_share...

読み飛ばしてOKのまえがき 現在、私はFlutterでアプリ開発にチャレンジしています📱 その開発内容もgit＆githubで管理していきたいなと思いました。アプリ開発をしているのは、iPhoneの実験もしたいことから、Mac機を使用しています。環境構築済みのWindows機ではないので、新たに環境構築が必要となります。 一度、Git＆Githubの本で一通り実施したので、それ程詰まらずに進めることができるだろうと思っていたのですが、思ったより時間を要してしまいました。 今後も新たなPCでGit＆Githubの環境構築をすることがあると思いますので、その方法をまとめておきたいと思います。 注意事項？ 全てCLI前提（Mac標準搭載のターミナル）で書いていきます。M1💻と記載しましたが、Apple silicon系であれば内容は同じと思われます。また、Windowsでも、パッケージマネージャー入れたり（必須ではない）、コマンド実行したり、流れや内容は概ね一緒かと思います。 実行手順 Homebrew🍺をHPにアクセスしてインストールする。PATHが追加されていない場合（インストール時にwarningが出る）、Users/ユーザー名/に.zshrcを作成する。.zshrcにexport PATH=/opt/homebrew/bin:$PATHを追記する。下記を実行して、追記内容を反映させる。 ※インストールしただけではPATHが登録されないのはM1の仕様みたい。 ※Homebrewインストールの参考ページ →Homebrewのインストール source .zshrc 下記を実行してバージョン情報が確認できれば問題なし。 brew -v 下記でパスの設定状況を確認するのも良い。 echo $PATH gitをインストールし、ユーザー名とパスワードを登録する（Githubと合わせる必要は特段無い）。下記を実行。 brew install git git confg -- global user.name ユーザー名 git confg -- global user.email メールアドレス 下記を実行すると、設定した内容を確認できる。特に問題なければOK。 git config --list Githubをリモートリポジトリに設定する為に、SSH Keyを設定する。任意のフォルダ（ユーザー名/など）で下記を実行して秘密鍵/公開鍵を作成する。-c "内容"を追記して実行すると、鍵にコメントが追記できる。コメントとしてメールアドレスを追記する作法があったようだが、特段必要は無いと思われる。-f "内容"を追記して実行すると鍵のファイル名を設定できるが、これも必須では無い。ファイル名を設定した場合は.sshフォルダ configファイルを作成してファイル名等を記載する必要がある。 ※ed25519は暗号化の種類。 ssh-keygen -t ed25519 鍵の置き場所を聞いてくるので、カレントディレクトリで問題無ければそのままENTERを押す。設定するパスフレーズを2回入力する。 ※パスフレーズはパスワードの対応文字数が多いバージョン。また、文字にスペースを設定可能。尚、フレーズ=単語を入力しろということではない。 ディレクトリ内にid_ed25519（秘密鍵）とid_ed25519.pub（公開鍵）が作成されていればOK。公開鍵の内容をコピーするために下記を実行する。Finderで直接開いて、内容をコピーしても同じ。 pbcopy < id_ed25519.pub GitHubにアクセスして、Settings→SSH and GPG keys→New SSH keyをクリック。TitleにはPCの種類等を記載して、Keyには公開鍵の内容をペーストする。Add SSH keyをクリックして、Github上の鍵の設定は完了。下記を実行する。 ssh -T git@github.com 実行の可否を聞いてくるので、yesと入力。Hi~と出てくればSSH keyの設定はOK。 Github上でリモートリポジトリを作成する。作成したリポジトリのSSH用URL（NOT https）をコピーしておく。 リモートリポジトリとローカルリポジトリを接続する。下記を実行。 git remote add origin SSH用URL ローカルリポジトリを作成したいディレクトリを移動する。下記を実行しローカルリポジトリを作成する。 git init Gitでadd→commit→pushを実行し、ローカルリポジトリの内容をリモートリポジトリに反映させる。下記を実行して、Gitのインデックスに登録（Git管理の対象になる）。 git add ....

Dart+Flutterを使用したAndroid、iPhoneのアプリ開発にチャレンジしてみようと思います。 Flutterをおさらい FlutterはWindows、MacOS、Linux、iPhone、Android、向けにアプリケーションを開発できるSDK（Software Development Kit・ソフトウェア開発キット）です。特に近年スマートフォンアプリの開発で注目されています。通常、スマートフォンのネイティブアプリの開発では、AndroidではKotlin+Android Studioが、iPhoneではSwift+Xcodeをが使用されると思います。しかし、Dart＋FlutterではどちらのスマートフォンOSにも対応した開発をすることができます。DartはFlutterで使用される言語ですね。 クロスプラットフォーム開発への憧れ Java+Android StudioでAndroidアプリの教本に載っているアプリを写経＋アレンジしたことがありますが、それだけでもやることが多く、それなりに大変だった記憶があります。しかも、当たり前ですが、Androidでしか動作しません。それが、共通のソースコードでAndroid、iPhoneのどちらにも対応できるなんて、何てお得💴なんだと思いました。お得なものは、みんな使用したくなりますよね！ それぞれの機器それぞれが持つ値のI/Oなど、仕様が異なる部分が盛りだくさんだと思うのですが、その辺りをどのように解決していくのか、楽しみでもあります。今のところ、センサーの値の引っ張ってきて何かをする予定はありませんが。 新しいものへの興味 Dartは2011年、Flutterは2017年に開発されたもので、比較的新しい開発手法です。何事もそうですが、新しいものに興味をソソられます。従来のものとはどのように差があるのか、どんな問題を解決していて、逆にどんな弱点があるのか、完全な上位互換なのか等が気になるタイプです。また、新しいということは、触れている人が少ないということでもあります。それは自分の個性の取得に繋がるかもしれませんし、まだ多くの人が見ていない景色を見ることが出来るかもしれません。未開の地🌏って、ワクワクしますよね。無人島だけが冒険じゃないんだぜ！ 尚、体系化された日本語リファレンスが圧倒的に少ないとうデメリットもあります。英語の公式ドキュメントを何とか読み解くか、数少ない日本語の参考資料を自分なりに繋げていく作業が必要になりそうです。 2022/09/01更新：日本語の公式ドキュメントありました。リサーチ不足でした😇 スマートフォンアプリ開発の実績の解除🎮 これから就職活動を行っていく上で、何が必要なのか、求人を見ながら考えました。条件等が合致しそうな企業の中に、スマートフォンのアプリ開発経験が必要なところがありましたので、その実績解除が出来れば良いと考えました。しかも、言葉の捉えようによってはAndroid、iPhoneのどちらのアプリも開発した実績を得ることが出来るので、お得だなという思いもありました（本当に捉え方次第ですが😂）。 スマートフォンというデバイスの面白み📱 パソコンやスマートフォン、VRゴーグルやグラス、時計や指輪等、色々なIT機器が出ています。その中でも、人の生活に溶け込んだデバイスをプラットフォームとした開発は、面白いのではと思っています。人がそのデバイスを頼りにする機会も多く、また直感的な操作感覚やその体験を、より直に感じやすいのではと思っています。UI/UXの凝り甲斐がありますね（挫折フラグ🚩）。 また、スマートフォンは圧倒的に普及しているデバイスなので、その広がりの大きさも魅力的だと思いました。作ったアプリケーションを、ITやその機器に詳しくないような、自分の身近な人に使って貰える可能性があるって、ステキじゃないですか！ 尚、挫折する可能性もありまして。。。 色々書きましたが、まずは最低限の機能で作っていくと思います。挫折が一番怖いですからね。 暖かく見守っていただき、挫折したなと見受けられる時はGitHubにスター🌟ください！　リリースできた時は倍スター🌟ください！

はじめに 本サイトはGitHubPages📄にて運用しております。 一般的なブログサービスは便利なものもたくさんあります。アカウントを登録すればすぐに開始できるし、機能も豊富で、至れり尽くせりです。 では、構築に手間がかかる（少なくともブログサービスよりは）GitHubPagesをなぜ選択したのかを、メリットを挙げながら振り返っていきたいと思います。 広告を載せる必要がない ブログサービスによっては、広告の表示が必須、もしくは広告の非表示が有料なところがあります。GitHubPagesに載る広告は自分でコントロールすることが出来るのが良いですね。 無料🆓 上記の広告の件が絡んできますが、ブログサービスによっては💰有料のプランが用意されている場合があります。逆に言うと、無料プランでは様々な規制が設定されています。アップロードできるデータサイズや、独自ドメインの利用の規制等が主だったところですね。GitHubにも有料プランが存在しますが、特定の機能に限られているので、無料プランでも十分な運用が可能です。 設計自由度が高い ブログサービスによっては、デザイン🎨が固定、もしくはほとんど固定されているところがあります。GitHubPagesは非常に設計自由度が高いです。これは反面、自分で何もかも用意する必要があるということでもあります。当然、本サイトのデザインテーマしかり、Hugoやjekyllという静的サイトジェネレーターしかり、様々な技術を利用させていただけます。しかし、英語の情報も多く、Git/GitHubの利用も必須なので、構築・運用ハードルが低いとは言えないと思います。 サービスの信頼性が高い GitHubはマイクロソフトが運営しており、倒産等によるサービスの停止リスクは低いと評価できます。また、GitHub、GitHubPagesの利用者は世界中におり、運営元にも信用がおけるので、利用者を無視するような形でのサービスに対する規制が行われるリスクも低いと考えています。運営側の考えが強く反映された結果、利用者目線とは異なるポリシーが敷かれてしまったブログサービスもあったります。 好きなことを書ける💖 ブログサービスによっては、ブログの内容を特定のジャンル（例えばIT技術）に制限するルールを敷いているところもあります。そこでは、個人的な日記やエッセイ的な内容を書くことはできなくなっています。そういった規制も、GitHubPagesならありません！ 使ってみようかなと考えたブログサービス一覧 Qiita はてなブログ Zenn おわりに 上記の内容より、私はGitHubPagesを選択しました。 当然ですが、GitHubPagesにデメリットが無いとは言いません。特に自由度の件はメリットとデメリットが表裏一体になっています。 また、特定のブログサービスにしか無いメリットもあったりします（つまりそれはGitHubPagesのデメリットとも言える）。SEOの強力さや、ネットブック📚の形式でコンテンツの販売ができるところもあります。ただ、このサイトは、少なくとも今のところマネタイズや発信力の高さみたいなところをあまり求めていなかったので、そのメリットとは合致しなかった感じですね。 ということで、今後も技術的な内容を中心にその他色々な内容を書いていけたらと思っています😁

なぜGitHubPagesを選んだのか 無料であり、広告がないのが魅力的でした。はてなブログやZennも検討しましたが、GitHubを使用した経験が乏しいので、練習も兼ねることが出来るのではと考えました。またGitHubを使い慣れておくとは、スキル💪として有用だとも考えていました。 ※記事をMarkdownで書くことは必須事項でしたが、どのサイトもその要件は満たしていました。 静的サイトジェネレーターになぜHugoを選んだのか GitHubPagesを使用していく上で候補に挙がったのが、jekyllとHugoでした。jekyllはビルドに時間が遅い等の問題が見受けられました。調べるとjekyllからHugoに切り替えたというサイトもちらほらあり、かつ開発の継続性も見受けられましたので、Hugo（＋PaperMod）を選択しました。 ※ただ、jekyllはGitHub推奨の静的サイトジェネレーターの様ですし、最初はそこから入っても良かったかもしれません。 参考にしたところ GitHub Pagesで作るウェブサイト開発入門 - 自分だけのホームページを無料で公開 Hugo+Github Pagesでプロフィールページを作ってみた 受難の日々（Error一覧）😥 configが従来生成されたconfig.tomlではなく、config.ymlを作る必要があった。これは選んだテーマにより違う部分の様なので、テーマの公式ドキュメントに書いてある内容だと思います。config.ymlの書き方もなかなか掴めず苦労しました。最終的には下記の公式ページにたどり着き、何とか事なきを得ました。 hugo-PaperMod installation sample config.yml hugo serverで生成したサイトがうまく表示できませんでした。http://localhost:1313/ にアクセスしても、Chromeが「このサイトにアクセスできません」と無情に表示するだけでした。しばらく生成された文章を眺めていると、hugo serverが実行されている間しかlocalのWebサーバーは有効にならない、と気付きました。生成が終わったから実行を止めないといけないと勘違いしており、生成する度にctrl+cで止めてからアクセスしちゃってました。そりゃ表示されないですよね。 Serving pages from memory Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender Web Server is available at http://localhost:1313/ (bind address 127.0.0.1) Press Ctrl+C to stop Press Ctrl+C to stop!! git cloneで取得したPaperModがhttp://localhost:1313/ の段階で動きませんでした。いくつか同様の事例を調べていると、git submoduleで導入している人が多かったので、実行してみたらうまくいきました（cloneしてきたフォルダは削除）。これは今のところ何が悪かったのか分かっていません。 上記の件と関連してURLやパスが異なるといったErrorが出ました（なぜかcloneで持ってきたフォルダは「PaperMod」、submoduleで持ってきたフォルダは「hugo-PaperMod」でした）。GitHub ActionsにこのURLやパスは存在しませんというErrorが出ており、気づきました。自分が誤った修正をしている場面もあり、なかなかErrorが治まりませんでした。 git initの実行したパスが自分の想定と異なっており、GitHub上に上がるのが上位階層のフォルダ１つのみという状況が続きました。GitHub ActionsからDocsフォルダが見つかりませんというError内容が出ており気づきました。結局は、正しい位置でGit initを実行し直した上でadd → commit → pushの一連の流れを行うとうまくいきました。まだGit、GitHubの操作に慣れておらず、随分と右往左往しました。 Repositoryの名前が不適切になっており、想定外のURLでGitHubPagesが公開されていました。それに伴い、baseurlが異なるのでサイト自体が全く表示されませんでした。Repositoryの名前を「github....

TL;DR 総じて良い書籍📘だと感じました。書籍内の演習は全て実践させていただきました。 自分の状況。 GitはInstallしていたが、使用実績はなかった。 GitHubのaccountは持っていたが使用できていなかった。 Visual Studio Codeはinstallしてあり、使用実績もあった。 拡張子やDirectory構造📁をある程度理解していた。 CLIには慣れていた。 htmlを編集したことがあった。 以上のような状況なので、PCの扱いを含めて何も分かっていないわけではありませんでした。ただ、上記のような経験が無くとも実践していけるように作ってあると思います。尚、IT関連の実務経験はありません。 良かったところ。 Git＆GitHubを学ぶ上で、良い書籍だと感じました。Teamを想定した開発の演習があるのですが、その内容も分かりやすく興味を持って取り組み続けることができました。 command lineで実施するところと、その結果がしっかりと表示してあり、勘違いをしにくい（自分がCommand Lineを打ち込む場面なのか実行結果を待つ場面なのかといった）のも進めやすかったです。 事前説明の項目と演習の項目がしっかりと分けられており、分かりやすかったです。反面、少し上長にも感じました（事前説明の段階で先んじて実行してしまったり等）。「いちばんやさしい」をタイトルにしている以上は仕方ないのかなぁとも思います。 ところどころにある「ワンポイント」で納得感を得ました。編纂事情の説明や、こんなこともできるよといった演習では扱いきれない、視座に富んだ内容が記載されていました。master/slaveがmainに変わりつつある話しとか、面白かったです。下記画像はP140。 公開鍵による認証手続き（今回はSSH）についても、丁寧に解説してあったと思います。こういった書籍を用いずに実践する場合は、躓きポイントになりそうですね。 自分が詰まったところ。 Pull Request先を誤ってfork元にしてしまいました（yasagit-2/ichiyasaGitSample Repository）。同じことをしてしまっている人も多くいるようで、私が訪問した時点で同様のRepositoryには41件（forkは300件超）のPull Requestが行われていました。書籍の読者の皆様、同じ間違いをするようで少し安心しましたｗ （Pull Requestは取り消すこともできるので、間違った方はそうすると良いかもしれません） ホームディレクトリの環境変数を変更するのに手間取りました。/c/Users/(Home Directory)にはすでにいくつかのFolderやFileが存在したので、そこに新たにFolderを作成し、その直下で作業を進めたいと考えました。しかし、SSH Keyを生成する際に自動的に指定されるのがHome Directoryだったので、その変更を余儀なくされました。結果、Git Bash上でSETXCommandを実行して、変更することができました。下記を参考にしました。操作自体は簡単だったのですが、Git Bashの再起動を実施していなかったので、結果が反映されていないことに気づくのに時間がかかりました。GUIで実施すれば問題なく、かつ早くできたと思いますが、CLIで操作したかったんです。。。 [Git] Git Bashのホームディレクトリを変更する SETXで環境変数の変更を間違えた場合に面倒なことがあるようですが、最終的にはPowerShellを用いて解決できるようでした。 Windows環境変数の設定に「SETX」コマンドを使ってはいけない理由 Repositoryの連携に手間取りました。上記の件でGit Bashを再起動したせいか、Remote Repository（GitHub）との連携が解消されており、Commitしたところ、下記の通知が流れました。ここでemailだけでも判別できるかなぁ、とか色々やって時間を食いました。 誤植らしきところ。 下記の画像のところです。行数の順番がおかしくなっており（114から始まり途中で90になっている）、記載に誤りがあると思われます。この内容はインプレス社のお詫びと訂正に載っていませんでした（2022年8月7日訪問時）。P215です。 いちやさGit インプレス社 まだ慣れないところ。 git init → git add → git commit git clone → git branch → git add → git commit → git push → Create Pull Request → Review → Merge → git pull git status, git diff, git checkout, git reset, git rm, git log, git remote...