2023/02/03

#マンホール（「はっしゅたぐまんほーる」）の試写に参加しました！

コメント数:
0 コメント
by dotnsf

マンホール関係者枠（？）で、映画 "＃マンホール" （読み方は「はっしゅたぐまんほーる」）のオンライン試写に参加させていただきました：

この映画の存在は SNS で以前から知っており、また好きな女優さんの一人である奈緒さんが出演されることもわかったので気になっていました。このたびマンホールマニア（笑）枠でこの映画の試写に参加させていただいた経緯でございます。「#マンホール」は 2/10 から一般公開されますが、一足早く鑑賞させていただきました。関係者の皆様、本当にありがとうございました。

実を言うと試写を見る前（苦笑）から、こんな感想を書くつもりでいました：

あんなオチが用意されているとは、とても奥の深い作品でした。マンホールだけに

・・・で、実際に観た感想ですが、、、いやあ舐めてました。ごめんなさい。まずタイトルの「ハッシュタグ・マンホール」について。自分のようなマンホール蓋愛好家の立場では「#マンホール」って確かにしょっちゅう検索に使ってるけど、事前の予告を観た限りではそういう話とは思えない。「ハッシュタグ」ってどういうことよ！？　と思ってましたが、なるほど SNS を駆使してストーリーが展開していく様子をタイトルに含めていたんですねー。

あと、この映画は「マンホール内に閉じ込められた男性がタイムリミットまでの脱出を試みる」話なので、どうしても一人芝居が多くなるだろうな、と予想していました。もしかするとつまらないと感じる時間が長くなってしまうかも・・・　という不安もありました（実際、大半が一人芝居だったように思います）が、自分も普段 SNS を使っていることもあり、SNS やネット素材をこれでもかというほど活用（悪用？）して知らない人との連帯で展開されていく様子は一人であって一人でないような、気が付くと引き込まれているような、痛快さと怖さを感じる映画でもありました。

そして終盤、「ここまで追い詰められてどうやって解決するんだろ？」と不安になってしまいました。試写時の約束でオチについては触れられないことになっていますが、、うーん、、深い！（謎）　これは実際に観てのお楽しみということで。

ちなみに、作品内で「マンホール蓋のデザインから地名を特定する」シーンがありましたが、これは我々マニアの得意分野でもあります。 σ(^o^)　最近のマンホール蓋は地域の文化に関わる意匠がデザインされることも多く、そういうのは見ればだいたいわかります。今回の作品で出てきた蓋そのものは全国共通のいわゆる「JIS 規格」モノだったように思いますが、この蓋は中央に市区町村章がデザインされていることが多いので、そこで特定可能です。ただ自分も全ての市区町村章を暗記しているわけではないので、あのスピードで特定できるのは相当なマニアがいたように感じました。　(^^;

そんなマンホール蓋マニアや愛好家が多く集まるのがツイッターの #manhotalk ハッシュタグと、全国の（実際には世界中の）マンホール蓋デザインとその位置情報が集まるマンホール SNS 「マンホールマップ」です。映画を通じてマンホール蓋デザインに興味を持った方がいらっしゃったら、ぜひこれらも覗いてみてください。そして是非地元のマンホール蓋を撮影して、マンホールマップに投稿してください。お待ちしております：

このたびは貴重な試写の機会をいただき、ありがとうございました。マンホーラー冥利に尽きる機会でした。

最後に改めて感想を：

あんなオチが用意されているとは、本当にとても奥の深い作品でした。マンホールだけに

タグ：: manhole; manhotalk; nao; 奈緒; マンホール; #マンホール

2023/01/23

git コマンド（だけ）で GitHub Pages を公開する

コメント数:
0 コメント
by dotnsf

GitHub から提供されている静的サイト公開機能である GitHub Pages 。Git 的には「特定ブランチの特定フォルダ以下を静的サイトとして公開する」機能です。GitHub のリポジトリとしてコミットされていれば、GitHub のウェブ UI を使って設定できます。

が、いくつかの制約事項はあるものの git CLI だけでも（GitHub のウェブ UI から操作しなくても） GitHub Pages を公開することもできます。その手順を確認したので以下に記載しておきます。

【前提条件】
GitHub リポジトリに静的サイトのページが公開登録されている前提が必要です。また GitHub ページとして公開したいコンテンツは "/" （つまりリポジトリ直下のフォルダ）にまとまっているものとします。

というわけで以下のようなリポジトリを作りました。リポジトリ直下に README.md, page1.html, page2.html という３つのファイルが存在しているものとします：

(https://github.com/dotnsf/gh-pages-sample)

それぞれの中身は以下のようになっています。３つのファイルでそれぞれリンクが設定されている、というだけの単純な内容です：

README.md

# README.md

- [ページ１](./page1.html)

- [ページ２](./page2.html)

page1.html

<html>
<head>
<title>ページ１</title>
</head>
<body>
<h1>ページ１</h1>

<a href="./">README.md</a>
</body>
</html>

page2.html

<html>
<head>
<title>ページ２</title>
</head>
<body>
<h1>ページ２</h1>

<a href="./">README.md</a>
</body>
</html>

このリポジトリをそのまま GitHub Pages で公開することにして、その手順を↓に紹介します（最後に応用の形でサブフォルダを GitHub Pages で公開する方法も紹介します）。

【git CLI での公開手順】
改めて GitHub Pages として公開したいリポジトリを参照し、その URL を確認します。今回の例であれば https://github.com/dotnsf/gh-pages-sample となります：

このリポジトリを git clone します：

$ git clone https://github.com/dotnsf/gh-pages-sample

$ cd gh-pages-sample

次に gh-pages という名前のブランチ（←ここが重要！）を作成して checkout します：

$ git checkout -b gh-pages

このブランチをリモートの gh-pages ブランチとして git push します：

$ git push origin gh-pages

ここまでの手順が成功すると、GitHub のリモートリポジトリ側にも gh-pages ブランチが作成されていることが確認できます：

（ここまでの手順で GitHub 上で GitHub Pages の設定はしていないのですが）"Settings" - "Pages" を選択して GitHub Pages の設定画面を確認すると、gh-pages ブランチの /(root) フォルダ以下が GitHub Pages として、 https://dotnsf.github.io/gh-pages-sample/ という URL で公開されていることが分かります：

この URL にウェブブラウザでアクセスしてみると、README.md の内容が GitHub Pages として確認できます：

ページ内のリンク部分をクリックすると想定通りのページに推移できます。GitHub ページとして期待通りに動いていることが確認できました：

ここで紹介したように gh-pages というブランチを作ってコミット＆プッシュすることで、そのコンテンツを GitHub Pages として公開することができるようです。これによってウェブ画面からの操作なしで GitHub Pages 公開が実現できます。

【（応用）特定のサブフォルダ以下を GitHub Pages として公開したい場合】
GitHub で gh-pages という特殊な名前のブランチに登録することで GitHub Pages として公開できることがわかりました。ただ上で説明した方法ではリポジトリのフォルダ全体を公開することになりました。特定のサブフォルダの中だけを GitHub Pages として公開する方法はないのでしょうか？

その方法がこちらです。例えばローカルリポジトリ内の web フォルダ以下を GitHub Pages として公開する場合は以下のように指定します：

$ git subtree push --prefix web origin gh-pages

gh-pages というブランチを指定するのは↑で説明したのと変わりませんが、"git push" ではなく "git subtree push" というコマンドを使います。またこの時に "--prefix フォルダ名" を指定することで指定フォルダの内容だけを gh-pages ブランチとして（＝GitHub Pages として）登録する※ことになります。

※少しややこしいのですが、この subtree push を使う方法で GitHub Pages を設定した場合、gh-pages ブランチに全ファイルが登録されて、その中の web フォルダ以下が GitHub Pages になる、というわけではありません。gh-pages ブランチに web フォルダ以下の全ファイルが登録されて、ルートフォルダ以下のファイル（つまりブランチ内の全ファイル）が GitHub Pages になります。つまり main ブランチと gh-pages ブランチではリポジトリのファイル構成が変わってしまう点に注意が必要です。

タグ：: git; github; pages; gh-pages

2023/01/17

OpenShift 上で RedHat CodeReady Workspaces オペレーターを使ってアプリケーション開発環境を作る

コメント数:
0 コメント
by dotnsf

ウェブアプリケーションの開発ハンズオン（オンライン含めて）を行う場合、その開発環境の準備が面倒です。参加者の PC を使おうとすると言語ランタイムやエディタのインストールやバージョン管理を含めて事前に準備してもらう項目が多く、また特にオンライン環境だとネットワークの設定が問題になったりするので、色んな環境のケースを想定した準備が必要になります。

そんな「開発環境構築」を比較的容易にする RedHat CodeReady Workspaces を使う機会があったので、使い方やこれを使って構築する開発環境がどんなものかまとめてみました：

【事前準備】
今回は RedHat OpenShift クラスタ環境を使って CodeReady Workspaces を準備します。というわけで OpenShift クラスタ環境が必要です。以下では IBM Cloud 上に作った OpenShift クラスタ環境を使って紹介しますが、他のクラウドやオンプレミス版などを使っていても構いません。

【OpenShift に RedHat CodeReady Workspaces を導入】
まずは OpenShift クラスタに RedHat CodeReady Workspaces を導入します。RedHat CodeReady Workspaces は OpenShift 上のオペレータとして提供されているのでこれを使って環境を作ります。最初に OpenShift のウェブコンソールを開いて、Administrator パースペクティブで左メニューから Operator - OperatorHub を選択します。そこでプロジェクト（例えば "default"）を１つ選び、検索フィールドに "codeready" などと入力して "Red Hat CodeReady Workspaces" を見つけてクリックします：

Red Hat CodeReady Workspaces の説明画面が表示されたら「インストール」ボタンをクリックします：

次の画面を下までスクロールしてもう一度「インストール」ボタンをクリックします：

ここでしばらく待つと RedHat CodeReady Workspaces オペレータがインストールされます：

インストールが完了すると以下のような画面になるので、「Operator の表示」ボタンをクリックします：

インストールされた RedHat CodeReady Workspaces オペレータが表示されます。実際に CodeReady Workspaces インスタンスを動かすために「提供される API」欄の "CodeReady Workspaces Instance Specification" の下の「インスタンスの作成」をクリックします：

もう一度下までスクロールして「作成」ボタンをクリックするとインスタンスの作成が始まります：

インスタンスが作成されると以下のような画面になるので、"codeready-workspaces" と書かれた箇所をクリックします：

下のような画面になります。この画面ではまだインスタンスは準備中ですが、用意ができると "CodeReady Workspaces URL" の下にリンク URL 文字列が表示されます：

このような表示になるとインスタンスの作成も完了しています。早速 CodeReady Workspaces URL 下のリンクをクリックします：

最初の１回だけアクセス権の設定を行う必要があります。"user-full" にチェックが入っていることを確認して "Allow selected permissions" ボタンをクリックします：

するとアカウント情報の画面が表示されます：

この画面内でユーザー名、メールアドレス、ファースト／ラストネームを入力して、最後に Submit ボタンをクリックします。これでアカウント情報の登録も行われます：

CodeReady Workspaces の起動が開始します。ここまで行うことができれば RedHat CodeReady Workspaces の環境構築手順は無事に成功しました：

【RedHat CodeReady Workspaces を使ってアプリケーション開発を行う】

RedHat CodeReady Workspaces の起動が完了すると最初のワークスペースを作るようナビゲートされます：

Git リポジトリを指定してソースコード一式をインポートすることもできますが、今回はテンプレートからワークスペースを作ってみます。（なんでもいいのですが）画面下の "NodeJS Express" と書かれた Node.js のシンプルなソースコードをベースに選択して、ここからワークスペースを作ることにしてみましょう：

すると指定されたテンプレートを元にしたソースコード一式が作成されるので、完了するまで少し待ちます：

ワークスペースの生成が完了するとこのような画面が表示されます。ウェブ版の VSCode が起動し、（今回の例であれば）シンプルな Node.js + Express のウェブアプリケーションの雛形となるソースコードが読み込まれています。指定したファイルを開いたり、その内容を変更することもできます（最初は README.md がプレビューモードで開かれています）：

依存関係や起動コマンドを確認するため、package.json を開いてみました。ここから最初に起動するべきファイルは app/app.js であることがわかります：

実際に app/app.js も開いて内容を確認してみました。いわゆる「ハローワールド」のウェブ版のアプリケーションのようです：

このアプリを起動するには VSCode 内でターミナルを起動します。メニューの Terminal - Open Terminal in specific container を選択し、"vscode-nodeajs" を選択します：

すると画面右下にターミナルが現れ、CLI コマンドを実行できるようになります：

実際にアプリケーションを起動してみましょう。まずはターミナルで "npm install" と入力してライブラリをインストールします：

そして "node app/app.js" と入力してウェブアプリケーションを起動します。すると画面右下に「起動したウェブアプリケーションをブラウザで表示するか？」と聞かれるので、「新しいタブで起動(Open In New Tab)」を選択します：

新しいブラウザタブが開いて、そこで起動したアプリケーションが実行されます。期待通り、"Hello World!" が表示できました。CodeReady Workspaces で作ったオンライン開発環境を使ってアプリケーションを開発／実行／動作確認までできることが確認できました：

CodeReady Workspaces のエディタ画面で編集したアプリケーションをウェブブラウザで実行（表示）することができました：

【まとめ】
OpenShift コンテナクラスタ環境を使うことで、開発環境も実行環境もコンテナ上で簡単に構築・実現することができました。個人の PC にはランタイムや CLI などを導入する必要がなく、ネットワークも（HTTP/HTTPS さえインターネットに通っていればいいので）環境による試行錯誤はほぼ不要だと思います。簡易的なアプリケーション開発環境の構築程度であれば非常に用意に作れると感じました。