bamboo’s blog

Bambooの気まぐれブログ

不定期日記（小型二輪免許を取ってきた話）

　こんにちは、Bambooです。今まで技術的な発信がメインでしたが、日記的な使い方もありかなーと思い、不定期で日記を書くことにしました。日記と言えど、その日の出来事を書くというよりは、思いついたことを思うがままに書き連ねるだけですが（笑）まあ暇なときにでも見てもらえると嬉しいです。

　というわけで、今回はバイクの話をしようと思います。なんでいきなりバイクの話かって話ですよね。実は最近小型二輪免許を取得したんです。高速には乗らないけど、原付の二段階右折や30km/h制限は面倒！ということで小型二輪(125ccバイク)に決めました。

普自二（普通自動二輪）追加！

実は小型二輪免許って普通自動二輪免許の区分なんですよ。原付二種とも言うのに、ややこしいですね（笑）

　免許の更新は既に済んでいるためすぐにでも乗りたいところですが、実はBamboo、125ccバイクを所持しておりません。なんなら原付バイクも持っていないので、ヘルメットも含めて購入しなければなりません。

　「よっしゃ、購入するぞ！！」という勢いでそのまま購入できればいいのですが、今のご時世そう簡単にはいきません。最近はコロナの影響で電車通勤からバイク通勤に変える人が増えてきたので、バイクの需要が以前より増えてるんですよね。一方で半導体不足や輸送の遅れなどによって供給量は減ってるんですよね。需要が増えて供給が減ったその結果、納車までの期間が全体的にかなり伸びているようです。噂によると、人気車種だと1年以上も待たなければならないのだとか。そんなに待ってられるかい！って話ですよね。

　そんな感じで今は新車の入手が非常に難しい状況。新車が買えないのなら中古でもいいだろうということで、中古車を探してはみるのですが、中古車も案外入手しにくい。皆さん考えることが同じで、おそらく新車が買えない分中古車に人が流れているのでしょう。いやー、本当に大変ですよね。まあこれに関しては文句を言ってもしょうがないので、いいバイクに出会えるまで気長に待ってみようと思います。

　ちなみに僕が購入を考えているバイクはPCXというバイクです。名前は聞いたことがあるという方は多いのではないでしょうか。原付二種でありながら快適な走行ができる、非常に優れたバイクです。さすがはホンダ車。

www.honda.co.jp

これがまた人気車種なのでなかなか手に入らないんですよね。待ってでも手に入れる価値はあるバイクだと思うので、これは少し辛抱ですね。

　いかかだったでしょうか。不定期日記、初回はバイクの話でした。それでは。

今後の運用予定

今まで思いつきをそのまま文章化してきた当ブログですが、もう少しちゃんと運用ルールを決めようと思います。

というのも、最近技術系のブログを書く場合にはQiitaで執筆したほうが執筆者同士の交流がしやすいのではないかと感じておりまして、、、

このブログは技術的な内容をメインに運営してきましたが、これからは基本的に技術系をQiita、その他の内容をこちらのブログに書いていこうかなと思っております。（場合によっては技術系をこちらに書くことがあるかもしれません。）

これからもどうぞよろしくお願いいたします。

↓↓↓良かったらQiitaの記事もぜひ見てくださいね！！

qiita.com

Online 3GX Builderの実装

はじめに

　Online 3GX Builderは、3gx(Nintendo 3DS向け拡張プラグイン)をオンラインでビルドできるツール。この記事ではどのように実装したかをざっくりと説明。

入力処理

　Online 3GX BuilderはHerokuでホスティングしている。普段Herokuで公開するサービスはGitHubからデプロイしていたが、某事件（詳しくはHeroku GitHub インシデントで検索）の影響でGitHubと連携できなくなったため、現在はHeroku単体でGit管理している。
　サーバー処理にはFlaskを使用している。特に理由はないが、以前にFlask+PyGithubでGitHub APIを使用したことがあったので、移植しやすいと考え採用。
　処理は以下のように行っている。

  1. ユーザーの入力からリポジトリのリンクを取得。
  2. リンクを解析し、有効なリポジトリのURLであるかどうか確認する。
  3. ビルド用のGitHub ActionsにPOSTリクエストを送信。パラメータとしてユーザー名/リポジトリ名を渡す。
  4. GitHub Actionsのページに遷移。

ビルド処理

　ビルドはGitHub Actionsで行う。作成当初、トリガー条件にはworkflow_dispatchを使用する予定だった。workflow_dispatchを使用すると、上記のようなHerokuのサイトを用意せずとも、GitHub Actionsのページで直接URLを入力してビルドを開始することができる。だがどうやらこの方法、リポジトリへの書き込み権限がある人でないと使えないらしい。つまり、一般の人がサービスとして利用することはできない。というわけで、外部からのPOSTリクエストで実行できるrepository_dispatchを使用。 　次にぶち当たった問題が、どのように3gxファイルをビルドするか。3gxのビルドには多くの依存関係があるため、自分でスクリプトを書くことはできなくはないが面倒だ。実はありがたいことに、PabloMK7氏が3gxビルド用Dockerイメージを公開してくれている。これは使うしか無い！というわけで、内部ではこのイメージを使用することにした。
　ビルドが正常に終了すると、成果物としてzipファイルに格納された3gxがアップロードされる。成果物はビルド画面の下部からダウンロードできる。

最後に

　需要は限定的だけど、こういうことができるとちょっと面白いよね。

動画

youtu.be

GitHubの公開鍵認証でSSHがハングした話

経緯

　先日リリースされたラズパイOSの64bit版にgitの設定を行っていたときに直面。ssh -T git@github.comで接続しようとしたところ、SSHセッションがハングし、強制終了せざるを得なくなった。

原因

　OpenSSHにはIPQoSというオプションが付いており、使用するルータによってはIPQoSを適切に処理できないらしい。

解決方法

　SSHの設定で、IPQoSの値を0に変更する。具体的には、~/.ssh/configに対して以下のように変更する。

Host *
  IPQoS=0

参考: ssh -T git@github.com hanging after showing "open confirm rwindow 32000 rmax 35000" message

CTRPFを使わずに3gxプラグインをビルドしてみる

はじめに

　3gxtoolという、3ds向けのプラグインを作成するツールがあります。通常はCTRPFと呼ばれるフレームワークを用いて作成しますが、今回はCTRPFを使わずに0からプラグインを作成してみます。

コード

　とりあえず最小のプログラムを作成してみましょう。start.sという名前で以下のようなファイルを作成します。

.global _start @外部から参照できるようにする

_start:
    bx lr @ルーチン終了

リンカスクリプト

　作成したプログラムを適切なアドレス配置にするため、リンカスクリプトを記述します。以下のプログラムを3gx.ldで保存します。（ちなみに、コード内にある0x07000100は3gxのエントリポイントのアドレスです。）

/* エントリポイント */
ENTRY(_start)

/* ヘッダ情報 */
PHDRS { text PT_LOAD; }

/* セクション情報 */
SECTIONS { .text 0x07000100 : {start.o} : text }

Makefile

　最後にビルドの情報や手順を記述するMakefileを作成します。以下のようなMakefileを作成してみましょう。

#ビルドルール取り込み
include $(DEVKITARM)/3ds_rules

#ターゲット名
TARGET      := tiny.3gx

#ソース名
SRC         := start.s

#ビルドディレクトリ
BUILD       := build

#使用するリンカ
LD          := $(CC)

#buildディレクトリが現在のディレクトリでない場合
ifneq ($(BUILD),$(notdir $(CURDIR)))

#Makefile内で実行するmakeに変数を渡す場合はexportを付ける

#ソースディレクトリ
export VPATH  := $(CURDIR)

#依存関係ファイルのディレクトリ
export DEPSDIR    := $(CURDIR)/$(BUILD)

#オブジェクトファイル
export OFILES := $(SRC:.s=.o)

#リンカに渡すフラグ
export LDFLAGS    := -T $(CURDIR)/3gx.ld -Wl,--gc-sections

#デフォルトターゲット
all: $(BUILD)

#buildディレクトリに移動するターゲット
$(BUILD):
  #buildディレクトリが無ければ作成
   @[ -d $@ ] || mkdir -p $@
  
  #buildディレクトリに移動し再度make実行
   @$(MAKE) --no-print-directory -C $@ -f $(CURDIR)/Makefile

#ビルド時の生成ファイルを削除するターゲット
clean:
   @rm -rf $(BUILD) $(TARGET)

#リビルドするターゲット
re: clean all

#buildディレクトリが現在のディレクトリの場合
else

#オブジェクトファイルに依存してビルド
$(TARGET): $(OFILES)

#中間ファイルの削除を防止する(デバッグのため)
.PRECIOUS: %.elf

#elfに依存して3gxを生成
%.3gx: %.elf
   @echo creating $@
  
  #3gxへの変換処理(plgInfoを渡さない場合は/dev/nullを指定)
   @3gxtool -d -s $(word 1, $^) /dev/null ../$@

#依存関係ファイル
-include $(OFILES:.o=.d)

#条件分岐終了
endif

makeコマンドでビルドすると、、、最小の3gxプラグインの完成です。

最後に

　今回作成した3gxプラグイン、サイズはなんと328 Byteでした。かなり小さいですが、ちゃんと動作します。もちろんですが、実用には程遠いので、普段は素直にCTRPFを使用してくださいね。

ghq+pecoでリポジトリ管理したら便利だった話

はじめに

　ある程度長い間プロジェクトを作ったり貢献したりしていると、ローカルリポジトリがごちゃごちゃしてくる。そんなとき、ふとインターネット記事で見つけたghq+pecoの組み合わせがかなり使いやすかったので、備忘録的な感じで残しておこうと思う。

インストール

　今回使用したのはUbuntu 20.04.3 LTS。ghqはgo getでインストールできる。

go get github.com/x-motemen/ghq

pecoは素直にaptコマンドで。

sudo apt install peco

ghq

　ghqはghq get <リポジトリURL>とするだけで、リポジトリをghqのルートディレクトリにクローンしてくれる。GitHub以外のリポジトリでも可能。デフォルトはhttpsなので、sshプロトコルでクローンしたいときは-pを付ける。

ghq + peco

　ここからが本題。ghqではデフォルトだと~/ghq/github.com/user/repoのような形式でクローンされる。だがこれだとパスが冗長で毎回打つのが面倒だ。
　そこで登場するのがpeco。pecoとghqを組み合わせることで、各リポジトリへの移動が格段に楽になる。

　以下のようなエイリアスを~/.bashrcにでも書いておく。エイリアス名はrepoにしてみた。

alias repo='cd $(ghq root)/$(ghq list | peco)'

repoと打つとghq getでクローンしたリポジトリが一覧表示され、目的のリポジトリに一発で移動することができる。

最後に

※今回の例ではエイリアス名をrepoにしましたが、どうやらAndroidのパッケージ管理ツールのコマンドと被るみたいなので、適宜変更してください。

ビジュアルプログラミングの必要性

ビジュアルプログラミングとは

　皆さんは「ビジュアルプログラミング」と呼ばれるものを聞いたことがありますか？プログラミングと聞くと、テキストでコードを記述する様子を想像するかもしれませんが、ビジュアルプログラミングはそうではありません。
　ビジュアルプログラミングでは、アイコンや絵などの視覚的なオブジェクトでプログラムを記述します。子ども向けの教育で使われることが多く、中でも有名な「Scratch」は聞いたことがあるという方が多いかもしれません。僕自身子ども向けプログラミング教室の講師をしているのですが、こちらでもビジュアルプログラミングを取り入れています。

必要性

　「プログラミング能力を培うのであれば、コーディングを覚えさせた方が良いのではないか」、そう思われる方がいるかもしれません。僕自身もかつてはそのように考えていました。しかし、プログラミング教育に広くビジュアルプログラミングが採用されているのには、れっきとした理由があります。

　第一に、子ども（特に低年齢の子ども）がいきなりコーディングを行うというのはなかなか難しいものです。通常のコーディングはキーボード操作や英単語などの覚えるべきことが多いため、習得に時間がかかり、子どもたちのモチベーションにも繋がりにくいです。
　このような弱点を解決するのがビジュアルプログラミングです。マウス操作でプログラミングが行えるため、通常のコーディングよりも直感的にプログラムを作成することができます。

　また、勘違いされることが多いのですが、プログラミング教育は「プログラミング能力を培う」ことが目的ではありません。プログラミング教育は「プログラミング的思考」を育むことを目的としています。文部科学省は、プログラミング教育とプログラミング的思考について以下のように述べています。

プログラミング教育とは、子供たちに、コンピュータに意図した処理を行うよう指示することができるということを体験させながら、将来どのような職業に就くとしても、時代を超えて普遍的に求められる力としての「プログラミング的思考」などを育むことであり、コーディングを覚えることが目的ではない。 小学校段階におけるプログラミング教育の在り方について（議論の取りまとめ）


自分が意図する一連の活動を実現するために、どのような動きの組み合わせが必要であり、一つ一つの動きに対応した記号を、どのように組み合わせたらいいのか、記号の組み合わせをどのように改善していけば、より意図した活動に近づくのか、といったことを論理的に考えていく力 小学校段階におけるプログラミング教育の在り方について（議論の取りまとめ）

文面から分かる通り、プログラミング教育は「プログラミングができるようになること」を目的としていません。あくまで「プログラミングを通して論理的に物事を考える力を身に付けること」を目的としています。ビジュアルプログラミングを用いることで、子どもたちに直感的でわかりやすい形でプログラミング的思考を身に付けさせることができます。

結論

　プログラミング教育が注目されているのは、別にプログラマを量産したいからなどというものではありません。プログラミングを通して論理的思考力を育み、主体的に物事を解決する力を身に付けさせるためです。この能力を身に付ける上で、ビジュアルプログラミングこそ最適な手段と言えるのではないでしょうか。