Ruby optparseライブラリの使い方～自戒も込めて～

optparseとは

rubyの標準ライブラリの一つである「optparse」は、ruby実行時のオプションを取得するためのものです。

まず、オプションって何？という方は、下の図を見ると分かると思います。

-aというオプションには、ALFA
-bというオプションには、BRAVO
を指定できることです。

つまり、このオプションが取得できるRubyの標準ライブラリが「optparase」です。
詳しい使い方はこのサイトに任せるとして、一つ小話を。

docs.ruby-lang.org

その前に、僕が一番使いやすい・直観的だと感じたコードを貼っておきます。

require 'optparse'

params = ARGV.getopts("a:","b:")
p params

ここにたどり着くまでの物語を。（そんな大層なことはない。）

使い方が分からなければ、検索しよう

僕は、検索しました。
たぶん、トップに出てきます。
※rubyというキーワードを付ければ、

docs.ruby-lang.org

上記のサイト内のコードを拝借しますが、
このライブラリの使い方はこうです。

require 'optparse'
opt = OptionParser.new

opt.on('-a') {|v| p v }
opt.on('-b') {|v| p v }

opt.parse!(ARGV)
p ARGV

実行例はこれです。

ruby sample.rb -a foo bar -b baz
# => true
     true
     ["foo", "bar", "baz"]

早とちりの僕は、この時点でこう思います。
欲しいのは、trueじゃない
ただの配列じゃない
僕が所望する出力はこういうの！。

{
   "a":["foo", "bar"],
   "b":["baz"]
}

こう思って、すこしイラつくこと10分。
自分の意図するコードを探すこと10分。
ついに発見。便利な機能。

OptionParser::Arguable

使い方は、こうです。

require 'optparse'

params = ARGV.getopts("a:","b:")
p params

リファレンスマニュアルの下のほうに書いてあります。
「加わりました」と書いてあるので、古いRubyでは動かないのかもしれません。 library optparse (Ruby 3.2 リファレンスマニュアル)

今回の学び

リファレンスを下までスクロールを。

おかしいな。いつも他人にはそう教えるのに。

Dockerを使ったrails開発環境を作成しよう

まえがき

説明の流れは、下記の記事で行っていきます。
ただ、環境が違いのせいかコピペでは、動作しませんでした。
そのため、自分用にファイルの中身を調整したものを使って動かしてます。

docs.docker.jp

※dockerとdocker-composeは、インストール前提で説明していきます。
　されていない方は、インストールをお願いします。

環境構築に必要なファイルを準備しよう

必要なファイル

  • Gemfile
  • Gemfile.lock （空のファイルです）
  • Dockerfile
  • docker-compose.yml

ruby・railsのバージョンは、自身が使いたいバージョン・既存のアプリケーションに合わせてください。

Gemfile

source 'https://rubygems.org'
gem 'rails', '~> 6.0'

Dockerfile

FROM node:18.16.0 as node

FROM ruby:3.0.2

ENV YARN_VERSION 1.22.19
RUN mkdir -p /opt
COPY --from=node /opt/yarn-v$YARN_VERSION /opt/yarn
COPY --from=node /usr/local/bin/node /usr/local/bin/
COPY --from=node /usr/local/lib/node_modules/ /usr/local/lib/node_modules/
RUN ln -s /opt/yarn/bin/yarn /usr/local/bin/yarn \
    && ln -s /opt/yarn/bin/yarn /usr/local/bin/yarnpkg \
    && ln -s /usr/local/bin/node /usr/local/bin/nodejs \
    && ln -s /usr/local/lib/node_modules/npm/bin/npm-cli.js /usr/local/bin/npm \
    && ln -s /usr/local/lib/node_modules/npm/bin/npm-cli.js /usr/local/bin/npx

RUN apt-get update -qq \
    && apt-get install -y postgresql-client

WORKDIR /myapp
COPY Gemfile /myapp/Gemfile
COPY Gemfile.lock /myapp/Gemfile.lock
RUN bundle install

EXPOSE 3000


どうせWebアプリをつくるなら、データベースも必要だよねってことで、PostgreSQLコンテナも用意します。

docker-compose.yml

version: '3'
services:
  db:
    image: postgres:15-alpine
    restart: always
    volumes:
      - postgres_volume:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=password
      - POSTGRES_HOST_AUTH_METHOD=trust
    ports:
      - "5432:5432"
  web:
    build: .
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    volumes:
      - .:/myapp
    ports:
      - "3000:3000"
    depends_on:
      - db
volumes:
  postgres_volume:

テンプレートファイルの作成

※既存アプリケーションを使って、開発する人はこの手順は不要です。
以下のコマンドを実行してください

docker-compose run web rails new . --force --database=postgresql

データベース作成

起動前にデータベースは作成した方がいいです。

docker-compose run web rails db:create

起動

docker-compose up -d

ようやく起動しました。以下のURLにアクセスして下さい。
http://localhost:3000/

後書き

Ruby・Railsのバージョンが違うだけで、
bundle installがコンテナ内で実行できなかったり
コンテナ内のDBにうまく繋がらなかったりと試行錯誤の繰り返しでした。

理論値と現在地と理想

人に教えると、ふと過る

他人に何かを教える時、
「自分って偉そうだな」と時々思う。
時々っていうのが味噌で、全体の９割方そんな感情は流れない。
ただ、困ったことに偉そうって思ってしまうことで、
詳しい説明を躊躇して、答えだけを教える傾向にある。
なので、流れないときの状況を考えてみた。
偉そうだと思わない。
そんな状況下に身をおけば解決するかもしれない。

偉そうだと思わない状況

  1. そもそも余裕がない時
  2. 自分の中の当たり前を通り越した時
  3. 教えることに集中している時

今のところは、この3つだろうと思う。
１の状況では、間違いなく答えのみを教えるという選択肢をとっているから、
今回の問題を解決する上で役に立たないだろう。
偉そうだと思いたくないなら、「すぐに答えを教えろ」という結論になってしまう。
２の状況では、教える相手が相当ポンコツで自分が異質な世界にいるという条件ではない限りは、意図的におこすのは現実的に無理だろう。
というか、もしそんな状況下に置かれ続けたら、 発狂する。
３の状況は、この状況にしようと努力はできる。
だが、無理だ。

さぁ、困ったもんだ。（終わり。）

カバーの裏

第４の条件を考えたら？

それは、無理。眠い。

タイトルと記事の関係性は？

特にない。
最近、ブログのタイトルと内容は必ずしも一致させる必要がないと感じてきたよ。
技術記事じゃないんだから。
おみくじ的なコンテンツだよね。
大吉って書いてあるのに、内容は微妙なやつみたいにね。

一応タイトルの意味を教えて

他人に教えるときは、まずその人の現在地を知ろう。
自分が勉強する時にみたいにね。
その現在地から、目に見える形で一歩ずつ踏み出す必要がある。
世間の熱い期待をコントロールするために。
人々は、その熱い期待をいつの間にか、理想という名の理論値に変えてしまう。
きっと頑張ればそこまで行けるだろと。
人は、その理想謎理論から生み出した基準を無自覚に強要することがあるよねって話。

結局何が言いたい？

僕、気を付けます。強要しないように。
やればできると本当にできるってのは、違うんだよな～。

vimの基本操作

vimとは

vimは、CUI上で操作が可能なテキストエディタです。
個人的には、常用したいと思ったことはありません。
しかし、SSHで接続したサーバー内での作業等で使います。今日も使いました。
覚えて損はなし。とういうか、使うショートカットキーは覚えるはず…
そんなツールです。
※vimを使いこなせる人は、お仕事出来るんだろうなぁと勝手に思ってます。
まずは、 Linux環境を準備してください。
（OSはMacでもWindowsでもいいと思いますが、結局サーバー運用作業で使うことが多いです。）

使い方

インストールしてない方は、以下のコマンドを実行してください。(apt系のみ、適宜sudo権限をつけるように)

apt-get install vim

ひとまず、vimを起動してみましょう。
以下のコマンドを実行してみましょう。

vim　test.txt

そしたら、黒の画面にチルダ（～）とtest.txt[New]の画面が表示されます。

vimの画面
vim起動が成功です。

そして次が最初の壁です。
テキストエディタなので、何か書き込みたいですよね。
しかし、書き込み操作はここでは受け付けてくれません。
vimで書き込むにはモードを切り替えなければなりません。

ノーマルモードとインサートモード

vimで文字を書くためには、インサートモード（挿入モード）にする必要があります。

i

これだけです。
そして、ノーマルモードに戻るには、Escキーと押してください。
困ったら「Esc」っていう呪文です。
では、再度インサートモードに切り替えましょう。
インサートモードに切り替える方法に i 以外にもあります。

操作 挙動（開始場所）
i カーソルの前から開始
I 行の先頭から開始
a カーソルの後から開始
A 行末から開始
o カーソルの下に行を挿入して、その挿入した行から開始
O カーソルの上に行を挿入して、その挿入した行から開始

ひとまず、iだけ覚えておけば良いと思います。
移動すればいいので。
ただ、覚えれば目的の場所まで行く手数が減ります。
vimを多用する人は覚えた方が、捗るかもしれません。

ノーマルモードは？

インサートモードの説明はしましたが、ノーマルモードの説明をしていませんでしたね。
ノーマルモードは、vimでの基本姿勢と言ってもいいかも知れません。
ノーマルモードでは、テキストファイル内の移動をします。
移動コマンドは、覚える必要はあるかはどうかは分かりません。
私たちには、矢印キーがあるので。
矢印キーが遠いと思われた方は、ショートカットキー（コマンド）を覚えてください。

※ノーマルモードでしてください。

操作 挙動（開始場所）
h 左
j 下
k 上
l 右

覚えずらいですね。
憶測ですが、kの上がiだったための悲劇ですね。
慣れたら、WASDのように動かせるんだそうです。

書き込んだものを保存する方法

保存するためには、コマンドモードを使いましょう。
ノーマルモードから：（コロン）打つと切り替わります。
基本的にwとｑを覚えておきましょう。

あとコマンドは、ひとまず不要です。
分かってきたら、使えるコマンドを増やしていきましょう。

操作 挙動（開始場所）
:w 書き込み
:q 閉じる（保存していない状態なら、警告が出ます）
:q! 強制的に閉じる（保存していなくても）
:wq 保存して削除

ではvim生活を楽しんで下さい。

これらの行き来をしながら、順風満帆なvim生活。

参考にした＆勉強した動画

分かりやすい動画をありがとうございました。
※この動画には、もっと詳しい内容が載っています。

現役シリコンバレーエンジニアが教える NeoVim(VIM) + Tmux + Zsh 入門 https://www.udemy.com/course/vim-tmux-zsh/

筆を執るか、僕を取るか

当たり前だが、僕を取る

久しぶりのブログである。
理由はさておき、非常に眠い。
まさに筆を執るか、僕の睡眠欲求を取るかだ。
それでも、不要でコスパの悪い考え事はするわけで、
今日は考え事でも、文字にしようと思う。
（今日に限らず、いつもです。正常です。）

急に始まる今日の一句

今日の考え事が、表せる句がある。
川を眺めていたら降りてきた。
という風に書けたらかっこいいのだが、少しその後手を加えた。

我ひたる　 水面を打つ音　 雨を待つ　

この句は、「ひたる」という言葉に
・雨の音に浸る自分
・気づいたら雨に濡れている（浸る）自分
という違い２つの視点を意味としてのせた。
（意味を解説するとかこっぱずかしい。AIにでも評価させてみるか。たぶん、やらない）
現状の自分と今に対してある種の楽さに身を任せている自分の状況を重ねたつもりだ。
たしかに、雨音は心地よい。
ただ、目の前で降っている雨は、こちらにやってくる。
水面を写真で取ろうと集中している間に、ずぶ濡れだ。
知らない間に、雨に降られる。
今の自分は、きっとそんなもんだ。
雨から逃げるなら、聞きほれている暇はない。
雨に濡れるつもりでも、覚悟はしないといけない。
選択する日は、きっと近い。

この句と説明の中に生まれる違和感 。

雨を待っている？
なぜに。諦めたのかい。
もう雨に濡れている？
なら、すでに手遅れではないか

これには、少し説明を。
今の状況を、天気に直せばどっちつかずの「くもり」である。
（「どっちつかずのつもりである」と対になってなんか面白い。ドラマの主題歌確定だね。）
という事から僕は、いつも思う。
雨・晴れという選択肢は変わるという意味ではさほど変わらないではないかと。
どこかへ踏みだした僕は
心地よいタイピングの音を響かせながら、楽しくエンジニアとして生きていくのだと。
そして、優越感　感慨に浸るのだから。
だから、この句の正しい読みは、「雨を待つ」「水面を打つ音」「我ひたる」。
それでも違和感？
そう感じた君は鋭いよ。
中七が8文字だから。
ここには書かない。眠いから。

後書き

やんでないよ。（病んでないよ）

web技術をちとかじろう

Web技術を支えている技術の紹介

誤解を恐れず、8割方おふざけで行きます。1
しっかり学びたい人は、こちらへ。

developer.mozilla.org

登場人物の入場です。

  1. ステートフル（stateful）
  2. ステートレス（stateless）
  3. リクエスト(request)
  4. レスポンス(response)
  5. クッキー(Cookie)
  6. プロトコル(protocol)
  7. ポート番号(port)

今日のWeb技術ライブ会場に集まってくれた子は、以上の７名だよ。
※説明の関係上、登場順番と関係なく説明していきます。

「プロトコル」が結ぶ不思議な握手

まず、このライブ会場で一番使われるのは、「リクエスト」と「レスポンス」。
一般の世界では、「コール」＆「レスポンス」というよ。2
出演者が呼びかけたら（コール）、観客が返す（レスポンス）が基本なんだ。
ここ（Web技術ライブ会場）でもアクセスするために、
ブラウザからWebサーバーに向けてリクエストするんだ。
そしたら、html・画像などをレスポンスするって、決まりなんだ。
この決まりのことを、「通信プロトコル」（今回はHTTP）というんだ。
間違えると、リクエストが届かないんだ。
実際のライブなんか、そうだよね。
思い付きのコールをすると、微妙な空気になるでしょ。
相手が人間の時でさえ、そうなんだから、
ましてや機械相手（サーバー）。
プロトコルを間違えた通信が届くわけないよね。
まぁ、安心して。
Web技術世界は安心設計。 ブラウザがサポートしてくれるから。

HTTPプロトコルの中身は、知りたいならこのリンクを見てね。

HTTP | MDN

話の都合上、ここから出演者と観客の関係性が逆になります。
前章では、出演者がメイン（一般ユーザー視点）でしたが、メイン（一般ユーザー視点）は観客に切り替わります。3

フルとレス

このライブに来てくれる観客には、2種類の楽しみ方をする人がいるよ。
それは、「ステートフル」と「ステートレス」だよ。
一般人の世界では、「ファンクラブ会員」と「非会員」というらしいね。

会員のチケット（ステートフル）には、登録している名前が印刷されているよ。
なぜって。
それは、ライブ運営元が君の情報を知っているからだよ。
なんなら、ライブ終わりに推しからメールが来ることだってあるかもしれない。
なぜって。
それは、ライブ運営元が君の情報を覚えているからだよ。

逆に、非会員のチケット（ステートレス）には、名前が印刷されてないよ。
（※実際にはチケット支払い時の名義が印刷されていることもあります。）
推しからのメールも来ないよ。
それは、ライブ運営元が君の情報を知らないからだよ。
どこに送っていいかが、分からないよね。

Web上のコンテンツは、基本的に何もしなければステートレスの状態だよ。
（※ブラウザにGoogleアカウント等の記憶させるている場合、違うこともあります。）
つまり、同じページ（ライブ）に何回足を運んだところで、君が来たということは伝わってないの。
それは、サーバー（ライブ運営元）が君の情報を知らないからだよ。
（※ただし、自己満足として、ブラウザの履歴に残ります。厳密にはアクセスログは残るよ。）
それでは満足できない君は、会員（ステートフル）にならないとね。
会員になる方法は、

  1. ライブ運営元に、君の情報を登録すること。
  2. アカウントを持っていることを証明すること。

これがすべてだよ。簡単でしょ。
ただ、2番の証明が大変なんだ。
Webでは、説明した通りプロトコル（HTTP）に沿った上で、
証明しないといけないんだ。

セッションという目には、見えない関係性

証明が大変だ。
でも、安心して。便利な奴がいるんだ。
「Cookie（クッキー）」って奴なんだ。
もし、彼がいなければ、
君はライブ会場に入る時だって、
ファンクラブのサイトを移動する時だって、
自分が会員であることを、自分で証明する必要があるんだ。
移動するたびに、IDとパスワードを手に持たなくてはいけないんだ。
つらいよな。
そこで、頼れるクッキー君の登場だよ。
彼は、必要とあらば君の頭に搭乗（登場）するんだ。帽子のようにね。
そして、代わりにＩＤとパスワードを持ち、君と一緒に移動してくれる。
これで、会員だと証明をしながら、君は手ぶらで移動ができるね。

でも、少し考えてみてよ。
いつも君の頭の上には、クッキー君。
つまり、ＩＤとパスワードが終始4頭の上。
不用心だね。

そこで日常でよく使われているのが、session（セッション）という連携技だね。
詳しくは説明しないが、
ページにログインすれば、特殊な文字列が発行されるんだ。
その発行した文字列を、クッキー君に渡すんだ。
そうすれば、アクセスする度にクッキー君が持っている文字列を見て、
サーバーが「この前のあの子だね」と通してくれるんだ。
顔パスだね。5
これで、君は「ステートフル」。

入り口は一つではない

実は、Webライブ会場の入り口は、実は一つじゃないんだよ。
知ってた？
普段君が利用する入り口は、80番・43番。
一般のライブでは、正面玄関がそれにあたるよ。
みんなが、利用する入り口だね。
でも、裏口もあるんだよ。
関係者専用入り口・機材搬入口のことだよ。
Webライブ会場の裏口は、21番（FTP）・22番（SSH）っていう入り口なんだ。
この番号を「ポート番号」と呼ぶんだよ。
まとめると、
ブラウザで利用するとき使う入り口は、TCPポート80、 TCPポート443。
Webサーバーの運用で使うのが、TCPポート21、 TCPポート22。

ちなみに、この扉は一定のルールを守れば、あけ放題だよ。
ただ、楽屋泥棒には気を付けてね。
そして、裏口から入る時は気を付けてほしいんだ。
ブラウザ上で煌びやかに輝いているHTML達が、文字列の塊だったいう事実。
（※一応ブラウザからでも、文字列して見れます。）
アイドルと同じだね。
あと、約束があるんだ。
コマンドを安易に使い、息の根を止めてはだめだよ。
バックアップは必ずとってね。
楽しいひと時が終わりを告げちゃうからね。

後日談

普通に書いた方が、楽だったのではと感じている。
そもそも、Web技術ライブ会場ってなんぞやって感じである。
ブログのタイトルを付けたときは、もっとまともに書くつもりのだったのになぁ。

しっかり学びたい人は、やっぱりこちら。

developer.mozilla.org

  1. 最後まで駆け抜けるために、一旦、自分を誤魔化す。しっかりしたものを書こうと意気込むと途中でやめたくなると思うから。卒業論文と同じ。後から肉付け。その後からは、きっと来ない。↩
  2. APIを呼び出すときにcallと使うので、Web技術世界でも「コール」＆「レスポンス」でもいいかもしれない。
    ↩
  3. すいません。書きながら違和感に気づきました。↩
  4. ※終始というのは、セッションが終わるまでを指します。
    ↩
  5. サーバー上に格納されているセッション情報とcookie上の文字列と照合する。↩

怒りの僕はコピペをする

なぜかコーディングで詰まる時

些細な事、コーディングが止まることがある。
エラーが出るわけでもない。ひっそりと、動かない。

今日のエラーは、この方でございます。
erbファイル内でのif構文さんです。
（言い訳：特に今回は動作環境がProgate上であるため、いつもより手間取った。ブラウザのほうを見ればよかったのだろう）
下記は、間違ったコードです。（動きません）

<%= if ○○ %>

10分ぐらい時間を無駄にしてしまった。
正誤判定をしてくださるProgate様に向かって、
「あってるんですけど！」と何回連呼したことか。
キーボードから手を放し、 PCとタイマンを張っているそいつが、
他人なら「プログラミングは向いてないよ」というかもしれない。
ただ、心配しないで。
そこで終わる人こそが本当に向いてないのである。
（負け惜しみである。）

このような時の解法（介抱）

それは、コピペです。（今回の事例だと） 間違っていると思われる箇所を探り当て
その行の下に、公式ドキュメントから取得した構文を！

<%= if ○○ %>
<%  if false %> ##公式からコピペ
<%= コメント %>　##公式からコピペ
<% end %>　　　　##公式からコピペ

そうすると、分かる。差分で気づく。
ifの前にイコールなど必要ないと。
怒る必要などない。
以上。

そもそも書いてある。公式ドキュメントより

以下の画像は公式ドキュメントから引用

出力がいらないコードのif構文さん

後日談　（実話です）

そもそも、progateをやりながら余計なことを考えてるのがいけないんだよな。
ふと思いついた小説の名前
「しばらく、名もなく、しょうもなく」
主人公は、3人にして会話劇にするか。
はたまた、1人にしてこの3つの回送をしながら旅をさせるか。
考えていた。
この小説に名前を付けたばかりに、 しばらく、こんなしょうもないことを考える羽目になりそうだ。

たぶん、これも技術記事ではない。